Concurrence des envois d’OTP par SMS : états, verrous et renvois
Point sur les limites de demandes d’OTP et les blocages temporaires, sans présumer de garanties de concurrence ou de livraison.
Le problème : plusieurs demandes pour une seule vérification
Un appui répété, deux onglets ouverts ou plusieurs requêtes reçues presque simultanément peuvent déclencher plusieurs demandes d’OTP. Cela peut générer plusieurs tentatives d’envoi ou laisser l’utilisateur avec des messages dont le statut n’est pas clair.
Les contrôles de fréquence et les blocages temporaires peuvent limiter les demandes. ClickSend décrit, par exemple, la possibilité de définir un maximum d’OTP par minute ou de bloquer temporairement des utilisateurs. Ces contrôles ne suffisent pas à établir comment des demandes simultanées sont coordonnées ni à garantir qu’un seul envoi sera lancé.
- Vérifiez si les demandes simultanées concernent la même vérification ou des vérifications distinctes.
- Distinguez la limitation du nombre de demandes d’une garantie de traitement unique.
- Ne déduisez pas de l’absence de réponse immédiate que l’envoi n’a pas été lancé.
Distinguez la vérification, le code et les tentatives d’envoi
Pour analyser les demandes répétées, distinguez la vérification OTP, le code associé et les tentatives d’envoi du SMS. Cette distinction aide à décrire ce qui s’est passé sans confondre une nouvelle vérification avec une répétition de demande.
Précisez ce que votre produit entend par « la même vérification ». Une demande répétée pendant une vérification en cours peut soulever des questions différentes d’une nouvelle vérification démarrée après la fin ou l’abandon de la précédente. Les éléments disponibles ne permettent pas de prescrire une politique universelle.
- Décrivez les étapes de la vérification et les tentatives d’envoi de façon distincte.
- N’utilisez pas le seul numéro de téléphone pour conclure que deux demandes correspondent à la même vérification.
- Évitez de présenter une règle de déduplication comme une garantie vérifiée si votre système et votre fournisseur ne la documentent pas.
Définissez clairement le périmètre des demandes répétées
Avant de décider comment traiter les demandes rapprochées, déterminez les éléments qui permettent à votre application de distinguer une répétition d’une nouvelle vérification. Ce choix relève de l’architecture et des règles de votre service ; les éléments disponibles ne valident aucune clé ou combinaison universelle.
Séparez cette décision des limites de fréquence et des blocages temporaires. Ces derniers peuvent restreindre les demandes, mais les sources disponibles ne précisent pas comment ils coordonnent plusieurs processus ni s’ils préviennent les envois en double.
- Documentez comment votre service distingue une demande répétée d’une nouvelle vérification.
- Expliquez séparément les règles de fréquence et les éventuels mécanismes internes de coordination.
- Ne présentez pas une architecture choisie comme une capacité garantie par le fournisseur sans documentation à l’appui.
Présentez les états et les mécanismes internes comme des choix d’architecture
Une application peut choisir de suivre les étapes de ses demandes et de ses tentatives d’envoi. Les noms des états et les transitions dépendent de ce que le système et le fournisseur permettent réellement d’observer. Les éléments disponibles ne valident pas de machine à états précise, de verrou atomique ou de méthode de récupération des opérations abandonnées.
Si votre système doit coordonner plusieurs processus, faites vérifier les mécanismes retenus au regard de son architecture et de sa documentation. Un contrôle de fréquence ou un blocage temporaire ne permet pas, à lui seul, de conclure que les processus ne traiteront pas simultanément une même demande.
- Décrivez ce que chaque statut signifie et quelle source l’a communiqué.
- N’affirmez pas qu’une transition est atomique sans preuve adaptée à votre système.
- Faites valider les choix de coordination et de récupération par la documentation technique applicable.
Ne présumez pas quand réutiliser ou remplacer un OTP
Les éléments disponibles ne permettent pas de recommander une règle générale sur la réutilisation d’un OTP encore valide, la création d’un nouveau code ou l’invalidation d’un code précédent. Ces décisions doivent correspondre aux règles de sécurité et de vérification de votre service.
Décrivez ce qui se passe lorsqu’un utilisateur demande un nouvel envoi et veillez à ce que les indications affichées correspondent au comportement réel de l’application. Ne prétendez pas qu’un nouveau code a été envoyé si l’application n’a pas lancé de nouvelle tentative.
- Documentez ce qui distingue une nouvelle vérification d’une demande répétée.
- Précisez la politique appliquée aux codes antérieurs, sans la présenter comme une règle universelle.
- Faites correspondre les messages affichés à l’état réellement connu de la demande.
Traitez les délais d’attente sans présumer du résultat
Si une demande d’envoi est suivie d’un délai d’attente expiré, les informations disponibles ne permettent pas de déterminer si le fournisseur a reçu ou accepté cette demande. L’expiration indique ce que votre application a constaté ; elle ne prouve pas, à elle seule, que le SMS n’a pas été envoyé.
Avant de relancer une demande, vérifiez la documentation technique de l’API ou de la connexion utilisée. Les sources disponibles ne permettent pas d’affirmer qu’une clé d’idempotence, une consultation d’état ou un autre mécanisme est proposé. En l’absence d’information vérifiable, n’assimilez pas le délai expiré à un rejet confirmé et ne présentez pas une nouvelle tentative comme sans risque.
- Distinguez « aucune réponse reçue » d’un rejet explicitement communiqué.
- Consultez la documentation applicable avant de vous appuyer sur un mécanisme de répétition ou de consultation d’état.
- Ne promettez pas qu’un seul SMS sera reçu lorsque le résultat de la première tentative est inconnu.
Ne confondez pas les contrôles internes et ceux du fournisseur
Votre application peut appliquer des limites de fréquence ou d’autres règles internes. Les sources approuvées ne permettent toutefois pas de vérifier que le fournisseur reconnaît et déduplique les demandes répétées, ni de préciser le comportement d’une API dans ce cas.
Vérifiez la documentation officielle correspondant à l’API ou à la connexion utilisée avant d’affirmer qu’une demande répétée sera traitée de manière idempotente. Ne déduisez pas une garantie de déduplication métier de l’usage d’un protocole ou d’un contrôle de fréquence.
- Distinguez les règles mises en œuvre par votre plateforme de celles documentées par le fournisseur.
- Ne revendiquez pas l’idempotence sans documentation technique applicable.
- En l’absence de confirmation, ne présentez pas le comportement des demandes répétées comme garanti.
Conservez une traçabilité sans surinterpréter les statuts
Pour comprendre les demandes répétées, consignez les informations opérationnelles disponibles, comme les étapes observées et les tentatives effectuées. Limitez les données personnelles enregistrées et appliquez des contrôles d’accès et une durée de conservation adaptés à vos obligations.
Un statut communiqué par un fournisseur ne doit pas être transformé en preuve de réception sur le téléphone sans élément qui l’établisse. Les informations disponibles ne permettent pas de déterminer ce qu’un état de livraison prouve dans chaque cas. Distinguez le résultat communiqué par le fournisseur de la réception vérifiée sur le terminal et de l’achèvement de la vérification OTP.
- Distinguez le résultat de la requête adressée à votre API de celui communiqué par le fournisseur.
- Consignez le motif d’une nouvelle tentative lorsqu’il est connu.
- Évitez d’exposer le code OTP dans les journaux opérationnels.
- Testez les demandes répétées et simultanées dans votre environnement, sans supposer que ces essais établissent une garantie générale.
Questions fréquentes
Une limite de fréquence garantit-elle qu’un seul SMS sera envoyé ?
Non. Une limite de fréquence peut restreindre le nombre de demandes selon la configuration, mais les éléments disponibles ne permettent pas d’affirmer qu’elle garantit un traitement unique ou un seul SMS reçu.
Dois-je générer un nouvel OTP chaque fois que l’utilisateur demande un renvoi ?
Les éléments disponibles ne permettent pas de recommander une règle universelle. Définissez et documentez la politique de votre service pour les demandes répétées, les nouveaux codes et les codes précédents.
Que faire lorsque l’envoi se termine par un délai d’attente expiré ?
Ne concluez pas que le fournisseur a rejeté la demande ni qu’il l’a acceptée. Consultez la documentation de l’API ou de la connexion utilisée avant de relancer et présentez le résultat comme incertain si vous ne pouvez pas le confirmer.
Un état de livraison confirme-t-il que le SMS est arrivé sur le téléphone ?
Les éléments disponibles ne permettent pas d’établir cette équivalence. Présentez le statut comme une information communiquée par le fournisseur et distinguez-le de la réception vérifiée sur le terminal et de l’achèvement de l’authentification.