Produits Entr'ouvert » Publik

Dans la confirmation de tests supplémentaires avec l'IdP DGFIP, j'opterai simplement pour que la seconde personne du foyer se voit refusé la connexion FC avec un message expliquant qu'il existe déjà un compte avec cette adresse de courriel. Elle devra se créer un compte sans FC puis le faire valider via le BO. Sur la page Mon compte, la liaison de compte doit aussi être rejetée si le courriel est déjà utilisé.

• ne pas considérer le mail comme validé lorsqu'il vient de FC
• soumettre la déliaison de FC à la validation d'un mail (il ne faut une source de confiance quand on met en place un mot de passe, sauf cas d'un annuaire externe, ex. LDAP)
• restreindre la validation de l'unicité du mail aux comptes ayant le flag email_verified

Concernant les partenaires (au CUT ou ailleurs) leur dire qu'on ne leur garantit pas l'unicité du mail. Ce n'est pas leur problème, le guichet et VdL qui se basent là dessus ne devraient pas, on leur sert un sub qui est l'identifiant unique et définitif de leur point de vue.

• lien de confiance avec l'utilisateur pour récupération de mot de passe, ou n'importe quelle action critique sur le compte
• notifications, dans ce cas on est moins concerné de savoir si la personne est vraiment la propriétaire du compte que sur le fait qu'elle est proche du propriétaire du compte

Le flag email_verified servirait à savoir si on est dans les deux cas ou seulement dans le deuxième.

Benjamin Dauvergne a écrit :

L'autre possibilité serait de créer dans ce cas un compte pour la personne en ignorant EMAIL_IS_UNIQUE mais on perd la garantie que nous apportait ce flag.

Et rattacher à chaque compte une liste d'adresse courriel, dont une serait définie comme primaire et devrait être unique s'il y a une déliaison FC?

Le problème c'est qu'on perde le lien une personne un compte que donne FC et qu'on veut nous aussi. Si les gens utilisent les même credentials pas de soucis, c'est leur faute, mais quand les gens utilisent des credentials différents (et c'est le cas ici) et se retrouvent à partager le même compte pour des raisons indépendantes de leur volonté c'est problématique.

techniquement je ne sais pas.
Mais fonctionnellement, et vu de loin, déroger à la règle 1 personne = 1 mail unique risque de poser des pbs de compréhension impossible à expliquer aux clients.
Je dis ça sans aucune connaissance des pb techniques.

On rencontre aujourd'hui 8 cas sur 5900 comptes dont 1250 comptes FC sur le déploiement CUT.

Je préférerai vraiment qu'on se laisse un peu de temps, voir comment les choses évoluent, avant de revoir le fonctionnement et revenir sur quelques "principes" : email unique, création de compte en FO avec FC mais email non vérifié, notamment.

Je vais faire quelques tests avec l'idp DGFIP aussi et demander à la dinsic s'ils ont des stats sur le sujet.

Eric (DINSIC) nous indique :

• FI Améli unicité du mail.
• FI DGFIP email non unique.
• FI La poste et mobile connect, on ne sait pas encore.

Ce qui nous pose problème c'est que des comptes FC distincts ait une même adresse email. Or, même si tous les FI assuraient l'email unique, cela ne garantiraient pas que deux FI FC ait pour deux comptes distincts toujours des adresses email différentes.

L'email du compte FC nous intéresse seulement pour un utilisateur qui arrive sur notre système authentifié avec FC, avec un sub inconnu, et non connecté localement.

• lorsque l'usager a cliqué sur le bouton FC sur la page de création : quand il revient, on veut lui créer un compte mais le courriel est déjà pris.
• lorsque l'usager a cliqué sur le bouton FC sur la page de connexion : quand il revient, "à la place" de la page de liaison de compte, on cherche l'email en base, on le trouve mais le compte a déjà un compte FC associé.

Partant de l'hypothèse que l'on conserve l'email unique, dans les deux cas on veut lui créer un compte mais l'adresse email doit être changée.

Donc on pourrait compléter les parcours ainsi :

• lorsque l'usager a cliqué sur le bouton FC sur la page de création : quand il revient, on veut lui créer un compte mais le courriel est déjà pris.
  • On lui affiche un message indiquant que le courriel est déjà utilisé par un autre compte, qu'il doit donc se créer un compte en utilisant une autre adresse email puis aller sur la page de son compte et se lier à son compte FC depuis cette page.
  • On lui affiche pour cela la page de création sans le bouton FC (ce doit être le comportement de cette page actuellement s'il y a une session FC).
  • A voir si on peut garder les infos FC pour les mettre dans le mail et qu'au retour de la création de compte, le compte soit automatiquement lié. Auquel cas on modifie le message d'explication pour enlever "aller sur la page de son compte et se lier à son compte FC".

• lorsque l'usager a cliqué sur le bouton FC sur la page de connexion : quand il revient, "à la place" de la page de liaison de compte, on cherche l'email en base, on le trouve mais le compte a déjà un compte FC associé.
  • On lui affiche un message indiquant que le courriel est déjà utilisé par un autre compte, qu'il peut soit se lier à un autre compte existant ou qu'il doit donc se créer un compte en utilisant une autre adresse email puis aller sur la page de son compte et se lier à son compte FC depuis cette page.
  • On lui affiche la page de liaison de compte avec le bloc identifiant/mot de passe pour la liaison à un compte existant et le bloc "création de compte FC" modifié notamment pour que le bouton "Créer" renvoie sur la page de création de compte. Cette modification du bloc peut se faire dans un second temps. Dans un premier temps l'usager va cliquer sur le bouton créer et ça devrait réafficher le message et la page.
  • A voir si on peut garder les infos FC pour les mettre dans le mail et qu'au retour de la création de compte, le compte soit automatiquement lié. Auquel cas on modifie le message d'explication pour enlever "aller sur la page de son compte et se lier à son compte FC".

Premier point, celui d'information à l'usager, à traiter dans #21292.