Development #69223
custom_user : vérification du numéro de téléphone par un challenge (envoi d’un code) à la création du compte
0%
Description
Le fait de pouvoir envoyer des SMS dans authentic, #65179, avance et il faut maintenant gérer la façon dont cette capacité d’envoi permet de vérifier le numéro de téléphone mentionné pour la première fois par l’usager dans authentic.
Cette vérification passe par un challenge, par exemple une séquence de chiffres, envoyé à ce numéro, que l’usager saisit ensuite dans un formulaire dédié.
La séquence :
· déclaration du numéro de téléphone
· envoi du code
· vérification de celui-ci
est régie par les mêmes contraintes en front que #69222.
Fichiers
Demandes liées
Révisions associées
add sms code related settings (#69223)
utils/misc: add sms code creation utilitary function (#69223)
add sms code model (#69223)
app_settings: add sms-related authentic2 settings (#69223)
utils: add registration sms code sending logic (#69223)
use phone number as registration means in form validation (#69223)
add a page for users to input their sms registration code (#69223)
views: make sms code trigger a standard registration finalization (#69223)
Historique
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #49212: Création de compte avec un numéro de téléphone mobile ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Sujet changé de custom_user : vérification du numéro de téléphone par un challenge (envoi d’un code) à custom_user : vérification du numéro de téléphone par un challenge (envoi d’un code) à la création du compte
Mis à jour par Paul Marillonnet il y a plus d'un an
- Statut changé de Nouveau à En cours
- Assigné à mis à Paul Marillonnet
Mis à jour par Paul Marillonnet il y a plus d'un an
- Fichier 0001-registration-display-phone-number-in-form-69223.patch 0001-registration-display-phone-number-in-form-69223.patch ajouté
- Fichier 0002-add-sms-code-related-settings-69223.patch 0002-add-sms-code-related-settings-69223.patch ajouté
- Fichier 0003-utils-misc-add-sms-code-creation-utilitary-function-.patch 0003-utils-misc-add-sms-code-creation-utilitary-function-.patch ajouté
- Fichier 0004-add-sms-code-model-69223.patch 0004-add-sms-code-model-69223.patch ajouté
- Fichier 0005-app_settings-add-sms-related-authentic2-settings-692.patch 0005-app_settings-add-sms-related-authentic2-settings-692.patch ajouté
- Fichier 0006-utils-shamelessly-steal-hobo-s-request-wrapper-69223.patch 0006-utils-shamelessly-steal-hobo-s-request-wrapper-69223.patch ajouté
- Fichier 0007-utils-add-registration-sms-code-sending-logic-69223.patch 0007-utils-add-registration-sms-code-sending-logic-69223.patch ajouté
- Fichier 0008-use-phone-number-as-registration-means-in-form-valid.patch 0008-use-phone-number-as-registration-means-in-form-valid.patch ajouté
- Fichier 0009-add-a-page-for-users-to-input-their-sms-registration.patch 0009-add-a-page-for-users-to-input-their-sms-registration.patch ajouté
- Fichier 0010-views-make-sms-code-trigger-a-standard-registration-.patch 0010-views-make-sms-code-trigger-a-standard-registration-.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
0001 : ajout du champ téléphone dans le formulaire d’inscription
0002 : les settings spécifiques
0003 : la fonction de création du code à envoyer par sms
0004 : le nouveau modèle pour la fonctionnalité
0005 : les app_settings spécifiques
0006 : le request_wrapper volé à hobo pour signer les appels à passerelle. Sans doute à voir si on peut faire un ticket pour mutualiser ce code, il y a un autre wrapper de ce genre dans chrono.
0007 : la fonction qui gère l’envoi à passerelle
0008 : la récupération du numéro de téléphone dans le formulaire d’enregistrement
0009 : la page qui permet à l’usager de saisir le code reçu
0010 : la finalisation de l’inscription (on rembraye sur la vue déjà en place), et les tests du déroulé complet de l’inscription
Deux choses qu’il faudrait peut-être voir, je regarde et ferai peut-être des tickets à part au besoin (à moins qu’on me dise qu’il faut corriger directement ici) :
· gérer l’inscription au sein d’une OU,
· gérer la next_url tout du long, pour pouvoir rembrayer sur l’écran de départ au moment où on a interrompu le parcours pour s’inscrire.
Jenkins rouge car un souci de pyupgrade (qui casse ensuite isort par ses modifications), que je ne reproduis pas en local, et jenkins n’affiche pas le diff, je regarde et je fais un ticket s’il s’avère que le problème ne vient pas de moi.
Mis à jour par Benjamin Dauvergne il y a plus d'un an
- Statut changé de Solution proposée à En cours
- 0001: je vois bien que email est mis à required=True si la méthode d'inscription par téléphone est requise, mais je ne vois pas de clean() pour valider qu'au moins mail ou phone sont présents (c'est peut-être plus loin, je lis dans l'ordre)
- 0002: ok
- 0003: ok
- 0004: on a déjà authentic2.models.Token pour ça (tu peux mettre le UUID.digest()) ou l'inverse tu utilises Token.uuid.bytes pour générer ton code SMS (je ne sais pas trop si on préfère envoyer des URL ou des codes courts, pour moi le premier est plus simple à utiliser)
- 0005: (c'est un peu difficile de dire ok ou pas quand le setting est introduit indépendamment du code qui l'utilise, je préfère quand c'est groupé)
- 0006: pourquoi ne pas directement utiliser celui dans hobo ? Pour les tests tu peux juste utiliser requests nativement. et en pas appeler ça requests_wrapper, juste requests.
- 0007: ok mais pas dans misc, un module sms (ça vaut pour create_sms_code plus haut), j'essaie de ranger un peu :)
- 0008: ok donc le check demandée en 0001 est là, c'est pervers :)
- plutôt que de poser en session le fait que le message de warning a été affiché, ajouter un champ caché warning-shown=1
- idem pour registered phone y mettre un champ caché avec un signature hmac du numéro (phone-signature=hmac(pohne, settings.SECRET_KEY))
- les champs cachés tu peux les poser d'office, simplement changer leur valeur dans self.data dans clean()
0010: je ne comprends pas bien si on gère un token ou un code, on choisit ? si c'est juste un token ça nous évitera une nouvelle vue je pense
Mis à jour par Paul Marillonnet il y a plus d'un an
Benjamin Dauvergne a écrit :
- 0001: je vois bien que email est mis à required=True si la méthode d'inscription par téléphone est requise, mais je ne vois pas de clean() pour valider qu'au moins mail ou phone sont présents (c'est peut-être plus loin, je lis dans l'ordre)
Ok, j’ai ajouté une méthode clean, testée, c’est mieux directement dans la validation du formulaire plutôt que ce qui est fait dans 0008.
- 0002: ok
- 0003: ok
- 0004: on a déjà authentic2.models.Token pour ça (tu peux mettre le UUID.digest()) ou l'inverse tu utilises Token.uuid.bytes pour générer ton code SMS (je ne sais pas trop si on préfère envoyer des URL ou des codes courts, pour moi le premier est plus simple à utiliser)
J’avoue que je ne me voyais pas utiliser le même modèle là, ça m’aurait paru pas assez factorisable. J’ai privilégié la séquence :
· on crée un objet SMSCode qui contient le numéro de téléphone candidat à l’inscription, l’UUID opaque de l’URL et la valeur du code à entrer par l’usager.
· la validation de ce code génère alors un token d’inscription à proprement parler. Ça permet notamment de simplifier 0010 qui rembraye sur le process d’inscription normal sans trop de modifs dans cette vue déjà existante.
Le fait que les deux objets aient un UUID opaque et partagent quelques champs me paraissaient une raison insuffisante pour tout regrouper dans un modèle. J’ai peur que ça embrouille le code plus qu’autre chose, pour moi c’est deux choses bien différentes mais je suis prêt à entendre des arguments contraires :)
- 0005: (c'est un peu difficile de dire ok ou pas quand le setting est introduit indépendamment du code qui l'utilise, je préfère quand c'est groupé)
- 0006: pourquoi ne pas directement utiliser celui dans hobo ? Pour les tests tu peux juste utiliser requests nativement. et en pas appeler ça requests_wrapper, juste requests.
Ok je tente dans le code d’importer celui d’hobo, avec un fallback sur ce nouveau requests_wrapper.
- 0007: ok mais pas dans misc, un module sms (ça vaut pour create_sms_code plus haut), j'essaie de ranger un peu :)
D’ac, j’ai tout mis dans un module authentic2.utils.sms.
- 0008: ok donc le check demandée en 0001 est là, c'est pervers :)
Pardon, il y a maintenant une méthode clean() dans le formulaire de 0001.
- plutôt que de poser en session le fait que le message de warning a été affiché, ajouter un champ caché warning-shown=1
- idem pour registered phone y mettre un champ caché avec un signature hmac du numéro (phone-signature=hmac(pohne, settings.SECRET_KEY))
- les champs cachés tu peux les poser d'office, simplement changer leur valeur dans self.data dans clean()
Là j’ai simplement copié sur ce qui était déjà fait dans l’enregistrement par email, où on manipule request.session['registration-allow-resend'] et request.session['registered_phone']. Je préféferais qu’on reste soit sur la session pour les deux modes d’enregistrement, soit par des champs cachés pour les deux. Qu’est-ce qui te choque à utiliser la session pour ces infos ? Je trouvais ça pas mal la façon dont c’est géré dans l’enregistrement par mail.
0010: je ne comprends pas bien si on gère un token ou un code, on choisit ? si c'est juste un token ça nous évitera une nouvelle vue je pense
Là on gère bien un token dans les deux cas, c’était la piste privilégiée dans cette série de patches : la demande d’enregistrement par SMS génère un SMSCode, dont la validation permet de rembrayer sur la vue d’enregistrement standard, basée sur un objet Token.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Statut changé de En cours à Solution proposée
(Pour le reste c’est corrigé dans la branche, fraîchement rebasée.)
Mis à jour par Benjamin Dauvergne il y a plus d'un an
- Statut changé de Solution proposée à Solution validée
utils: shamelessly steal hobo's request wrapper (#69223)
Il ne faut pas le copier il faut l'utiliser directement et ajouter la dépendance.
Mis à jour par Paul Marillonnet il y a plus d'un an
Benjamin Dauvergne a écrit :
[...]
Il ne faut pas le copier il faut l'utiliser directement et ajouter la dépendance.
Je pensais qu’on favorisait toujours un fonctionnement standalone lorsque possible. Dans la branche, le patche d’après fait :
+try: + from hobo.requests_wrapper import Requests +except ImportError: + from .requests_wrapper import Requests +
Ce n’est que si hobo n’est pas installé qu’on utilise cette copie locale un peu remaniée.
Mis à jour par Benjamin Dauvergne il y a plus d'un an
À mon avis ce bateau est parti il y a longtemps, tu peux éventuellement faire juste :
try: from hobo... except ImportError: from requests.sessions import Session as Requests
Mis à jour par Paul Marillonnet il y a plus d'un an
Benjamin Dauvergne a écrit :
À mon avis ce bateau est parti il y a longtemps,
Ah bon ok, au temps pour moi.
tu peux éventuellement faire juste :
[...]
Ok je fais ça, je pousserai ensuite.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Statut changé de Solution validée à Résolu (à déployer)
commit 3582bad6b3f3cf807a34df840509f54d507420d3
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 12 11:48:20 2022 +0200
views: make sms code trigger a standard registration finalization (#69223)
commit 26f9d2098dc30168f67f87528db82ba9d703b608
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Thu Oct 13 13:27:51 2022 +0200
add a page for users to input their sms registration code (#69223)
commit e35275fe451bc6c9bdbe860907c990c4af35705d
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 09:30:23 2022 +0200
use phone number as registration means in form validation (#69223)
commit d40f5d382c07204da79e3b2301866fff195e03b7
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Mon Oct 10 09:35:10 2022 +0200
utils: add registration sms code sending logic (#69223)
commit c9906d4a628a491ce926ba0c86069019aadef00c
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 10:36:47 2022 +0200
app_settings: add sms-related authentic2 settings (#69223)
commit bd17c8915a3bf68a4b25741713c63b7ed51d607a
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 09:16:40 2022 +0200
add sms code model (#69223)
commit ff50dcf4f09c74c0b751ae32dfebd874bc5ec733
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 09:14:57 2022 +0200
utils/misc: add sms code creation utilitary function (#69223)
commit 2741f474b03bf718afe3432895bc52b4da87e928
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 09:14:41 2022 +0200
add sms code related settings (#69223)
commit 57da31b3f7e35f116300dead2a31fd52d38301f7
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Wed Oct 5 08:52:16 2022 +0200
registration: display phone number in form (#69223)
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #72441: registration : conservation de la next_url tout au long de la séquence d’enregistrement par numéro de téléphone ajouté
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
registration: display phone number in form (#69223)