obtenir des effets secondaires par rapport à la réinitialisation du mot de passe

Question

Généralement, une requête get n'est pas censée avoir d'effets secondaires. Cependant, de nombreux sites vous permettent de réinitialiser votre mot de passe ou d'authentifier votre adresse e-mail/utilisateur en cliquant sur un lien intégré dans l'e-mail. Puisque nous ne voulons pas envoyer d'e-mails HTML et ne pouvons donc pas utiliser un formulaire dans lequel les données sont postées, nous devons utiliser une requête get. Cependant, il est considéré comme mauvais pour avoir des requêtes utilisant GET avec des effets secondaires. Quelle est votre opinion à ce sujet? Y a-t-il un moyen de résoudre ce dilemme?

Answer 1

Normalement, ces liens contiennent uniquement un jeton qui identifie l'utilisateur qui veut réinitialiser le mot de passe resp. la demande de réinitialisation du mot de passe. Il ne se connecte pas à l'utilisateur.

Ensuite, un formulaire est affiché où l'utilisateur peut créer un nouveau mot de passe. Quoi qu'il en soit, qu'une requête GET doit être idempotente n'est pas un fait difficile, c'est plutôt une ligne directrice. Si cela améliore la convivialité pour l'utilisateur de ne pas s'en tenir à cette ligne directrice plutôt que d'y aller (après avoir examiné les alternatives et les conséquences bien sûr). En fin de compte, la convivialité compte. Mais si vous voulez réinitialiser le mot de passe en générant un mot de passe aléatoire et l'envoyer à l'utilisateur, ne le faites pas. L'envoi de mots de passe en clair dans des courriels non cryptés est une très mauvaise idée. Dans ce cas, je préférerais la sécurité avant l'utilisabilité et laisser l'utilisateur le choisir lui-même.

Mise à jour

btw. un point très important avec ces URL est qu'elles ne sont normalement accessibles qu'une seule fois ou du moins tant que l'utilisateur n'a pas terminé la procédure. Donc, bien que vous puissiez changer quelque chose avec la requête GET, la ressource sera supprimée de toute façon.

Answer 2

Oui, pour créer un lien vers une page qui n'a pas d'effets secondaires POST pour effectuer la réinitialisation.

Answer 3

GET doit être idempotent - obtenir la même ressource devrait donner la même valeur, et il devrait être sûr. La sécurité implique que l'utilisateur ne soit pas tenu responsable de tout effet secondaire. Bien que l'idempotence et la sécurité impliquent généralement l'absence d'effets secondaires, j'accueillerais la réception d'un email ou la réinitialisation d'un mot de passe pour être à la fois idempotent et sûr - accuser réception ou demander un formulaire pour réinitialiser plus d'une fois ne modifie pas la ressource (en supposant que la réponse à la réinitialisation du mot de passe est d'afficher un formulaire POSTé pour entrer un nouveau mot de passe). Si un utilisateur avait un agent de messagerie qui récupérait et mettait en cache toutes les URL dans les messages, alors l'effet que l'utilisateur aurait involontairement déclenché serait d'avoir accusé réception de l'e-mail (ce qui est inoffensif, et 'vrai'), ou récupéré par inadvertance un formulaire pour réinitialiser son mot de passe. Si le lien de réinitialisation réinitialise réellement le mot de passe sur le GET plutôt que sur le POST du formulaire, il est un peu plus gris, mais plus problématique que toute autre chose - si le jeton de réinitialisation n'est bon que pour un nombre de hits donné, alors il ne peut constituer un déni de service.

Answer 4

Ceci est un usage intéressant, et je crois que c'est une pratique acceptable. Mais ce n'est pas une exception à la règle. Fondamentalement, la façon dont cela est généralement mis en œuvre, vous devez d'abord initier la réinitialisation du mot de passe d'une manière différente, généralement en entrant votre nom d'utilisateur ou votre adresse e-mail dans un formulaire POST.

Vous pouvez considérer cette requête POST comme essentiellement l'opération qui réinitialise votre mot de passe. Mais même si vous avez commencé le processus de réinitialisation du mot de passe, le système doit toujours vérifier votre identité. Cela est généralement effectué en envoyant un message SMS ou un courrier électronique avec un jeton de code/sécurité lié à cette demande POST.Tout le processus doit être complété pour que le système reçoive ce code de votre part de la façon la plus simple possible. Vous pouvez soit le taper dans un autre formulaire POST (par exemple, si vous le recevez par SMS), soit il pourrait être intégré dans un lien e-mail. Par conséquent, même si, techniquement parlant, votre requête GET finale a un effet secondaire, il s'agit toujours d'une opération idempotente. Parce que ce lien, à lui seul, ne fait rien sauf si vous avez déjà fait la requête POST antérieure pour démarrer le processus de réinitialisation. Et toutes les demandes ultérieures à cette URL GET n'auront aucun effet.

Edit:

Je pense qu'il convient également de noter que la mise sur le lien dans un e-mail le problème de contourner webcrawlers le déclenchement accidentel de vos opérations non idempotents. De plus, le fait que la plupart de ces liens redirigent immédiatement vers une page sans effets secondaires et le fait que la page elle-même ait un jeton à usage unique signifie que les boutons de retour et d'actualisation ne peuvent causer aucun effet indésirable non plus.