Conservation de la next_url tout au long de l’enregistrement par numéro de téléphone (#72441) #64

Merged
pmarillonnet merged 1 commits from wip/72441-phone-registration-next-url into main 2023-06-12 16:48:34 +02:00
Owner

Je pense qu’on doit pouvoir attraper au passage le même comportement pour la ré-initialisation de mot de passe, le code qui gère la création et la ré-initialisation étant assez factorisé pour cela.

Je pense qu’on doit pouvoir attraper au passage le même comportement pour la ré-initialisation de mot de passe, le code qui gère la création et la ré-initialisation étant assez factorisé pour cela.
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 3f05251e32 to 46fba8856a 2023-06-01 11:15:27 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 46fba8856a to 15f3a13474 2023-06-01 11:40:36 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 15f3a13474 to 5cf8ddf8f0 2023-06-01 11:50:41 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 5cf8ddf8f0 to 04674d24fe 2023-06-01 14:14:58 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 04674d24fe to 4bcbfc15b5 2023-06-01 15:23:35 +02:00 Compare
pmarillonnet changed title from WIP: Conservation de la next_url tout au long de l’enregistrement par numéro de téléphone (#72441) to Conservation de la next_url tout au long de l’enregistrement par numéro de téléphone (#72441) 2023-06-01 15:26:12 +02:00
Author
Owner

Je pense qu’on doit pouvoir attraper au passage le même comportement pour la ré-initialisation de mot de passe, le code qui gère la création et la ré-initialisation étant assez factorisé pour cela.

Bon, déjà mettons-nous d’accord sur l’approche pour la création de compte, ensuite l’extrapolation à la ré-initialisation de mot de passe sera rapide.

Une approche proposée ici en stockant le contenu de la next_url dans l’objet SMSCode, puisqu’on fait déjà quelque chose de similaire dans l’objet Token (utilisé pour la création de compte quelque soit le moyen, email ou téléphone).

> Je pense qu’on doit pouvoir attraper au passage le même comportement pour la ré-initialisation de mot de passe, le code qui gère la création et la ré-initialisation étant assez factorisé pour cela. Bon, déjà mettons-nous d’accord sur l’approche pour la création de compte, ensuite l’extrapolation à la ré-initialisation de mot de passe sera rapide. Une approche proposée ici en stockant le contenu de la `next_url` dans l’objet SMSCode, puisqu’on fait déjà quelque chose de similaire dans l’objet `Token` (utilisé pour la création de compte quelque soit le moyen, email ou téléphone).
vdeniaud requested changes 2023-06-08 15:37:06 +02:00
vdeniaud left a comment
Owner

C'est cryptique comme du authentic (set_home_url du grand art), quelques questions/remarques mais j'ai testé et ça fonctionne.

(je me demande un peu dans quelle mesure la next-url n'aurait pas pu être passée explicitement tout au long du parcours, puisqu'il est continu contrairement au parcours d'inscription via courriel où passer par la db est nécessaire)

C'est cryptique comme du authentic (`set_home_url` du grand art), quelques questions/remarques mais j'ai testé et ça fonctionne. (je me demande un peu dans quelle mesure la next-url n'aurait pas pu être passée explicitement tout au long du parcours, puisqu'il est continu contrairement au parcours d'inscription via courriel où passer par la db est nécessaire)
@ -836,3 +836,3 @@
created = models.DateTimeField(verbose_name=_('Creation date'), auto_now_add=True)
expires = models.DateTimeField(verbose_name=_('Expires'))
sent = models.BooleanField(default=False, verbose_name=_('SMS code sent'))
next_url = models.URLField(verbose_name=_('Next URL'), null=True, blank=True, default=None)
Owner

Je crois que c'est plutôt une mauvaise pratique de mettre null=True sur un champ texte (plutôt mettre juste default='')

Je crois que c'est plutôt une mauvaise pratique de mettre null=True sur un champ texte (plutôt mettre juste default='')
Author
Owner

Ok, j’ignorais cela. Je fais le changement ou alors j’abandonne carrément ce champ pour passer la next-url dans la querystring tout du long, comme évoqué plus haut.

Ok, j’ignorais cela. Je fais le changement ou alors j’abandonne carrément ce champ pour passer la next-url dans la querystring tout du long, comme évoqué plus haut.
@ -757,3 +757,3 @@
)
params = {REDIRECT_FIELD_NAME: next_url}
return make_url('registration_register', params=params)
return make_url('registration_register', params=params, next_url=next_url, sign_next_url=True)
Owner

Pourquoi y a-t-il besoin de ça ? (vs la création par email où pas besoin)

Pourquoi y a-t-il besoin de ça ? (vs la création par email où pas besoin)
Author
Owner

Parce qu’en imposant l’URL signée on s’épargne le cas de petits malins qui récupéreraient des listes d’usagers et envoient des mails du genre “Pour bénéficier du nouveau service machin de votre collectivité, créez-vous un compte à l’adresse https://authentic.collectivité/register?next=<url-du-site-foireux>.”

Je pense qu’à terme on pourra l’imposer aussi pour l’enregistrement par email, mais actuellement il y a trop d’existant de ce côté là pour le passer en douce dans cette PR. Ça doit faire l’objet d’une PR à part pour l’existant, je crois.

Parce qu’en imposant l’URL signée on s’épargne le cas de petits malins qui récupéreraient des listes d’usagers et envoient des mails du genre “Pour bénéficier du nouveau service machin de votre collectivité, créez-vous un compte à l’adresse `https://authentic.collectivité/register?next=<url-du-site-foireux>`.” Je pense qu’à terme on pourra l’imposer aussi pour l’enregistrement par email, mais actuellement il y a trop d’existant de ce côté là pour le passer en douce dans cette PR. Ça doit faire l’objet d’une PR à part pour l’existant, je crois.
@ -1308,6 +1314,8 @@ class InputSMSCodeView(cbv.ValidateCSRFMixin, FormView):
self.code = models.SMSCode.objects.get(url_token=token)
except models.SMSCode.DoesNotExist:
return HttpResponseBadRequest(_('Invalid request'))
self.next_url = self.code.next_url or utils_misc.select_next_url(request, None)
Owner

Dans quel cas le or utils_misc.select_next_url(request, None) s'exécute ?

Dans quel cas le `or utils_misc.select_next_url(request, None)` s'exécute ?
Author
Owner

Un bout de code qui reste (de cas limites avérés ou imaginaires de ma part, où la next_url changerait en cours de parcours) avant que soit prise la décision d’imposer la signature. Je retire ce bout de code qui n’est plus nécessaire.

Un bout de code qui reste (de cas limites avérés ou imaginaires de ma part, où la next_url changerait en cours de parcours) avant que soit prise la décision d’imposer la signature. Je retire ce bout de code qui n’est plus nécessaire.
Owner

C'est cryptique comme du authentic

> C'est cryptique comme du authentic
Author
Owner

(je me demande un peu dans quelle mesure la next-url n'aurait pas pu être passée explicitement tout au long du parcours, puisqu'il est continu contrairement au parcours d'inscription via courriel où passer par la db est nécessaire)

Au moment de l’écriture de la PR, ce choix me paraissait clair, notamment dans le fait que certaines des vues sont partagées avec l’enregistrement par email. À relire le code maintenant ce n’est plus si clair. Je vais voir si on a intérêt à passer cette url en querystring tout du long.

> (je me demande un peu dans quelle mesure la next-url n'aurait pas pu être passée explicitement tout au long du parcours, puisqu'il est continu contrairement au parcours d'inscription via courriel où passer par la db est nécessaire) Au moment de l’écriture de la PR, ce choix me paraissait clair, notamment dans le fait que certaines des vues sont partagées avec l’enregistrement par email. À relire le code maintenant ce n’est plus si clair. Je vais voir si on a intérêt à passer cette url en querystring tout du long.
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 7d34eac7e4 to 91cf8fcaad 2023-06-12 15:27:05 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 91cf8fcaad to 8421a7384d 2023-06-12 15:38:10 +02:00 Compare
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 8421a7384d to 8571c56ec4 2023-06-12 15:43:15 +02:00 Compare
pmarillonnet requested review from vdeniaud 2023-06-12 15:43:54 +02:00
pmarillonnet force-pushed wip/72441-phone-registration-next-url from 8571c56ec4 to b31361d02b 2023-06-12 15:44:10 +02:00 Compare
Author
Owner

Voilà, remarques prises en compte, c’est plus simple ainsi en effet.

Voilà, remarques prises en compte, c’est plus simple ainsi en effet.
vdeniaud approved these changes 2023-06-12 16:11:36 +02:00
pmarillonnet merged commit 19f3e080fb into main 2023-06-12 16:48:34 +02:00
pmarillonnet deleted branch wip/72441-phone-registration-next-url 2023-06-12 16:48:34 +02:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/authentic#64
No description provided.