Produits Entr'ouvert » Authentic 2

Paul Marillonnet a écrit :

Je pense notamment à la liaison de compte avec FC, où actuellement si l'email diffère, l'adresse email d'origine dans Publik est écrasée par l'adresse email renvoyée par le fournisseur d'identité FC.

Ce n'est pas le cas sur GLC (ou le CUT) qui a une configuration un peu différente de la configuration de base Publik :

 89     'email': {
 90         'ref': 'email',
 91         'if-empty': True,
 92         'tag': 'email',
 93     },
 94     'email_verified': {
 95         'ref': 'email',
 96         'translation': 'notempty',
 97         'if-tag': 'email',
 98     },

qu'on pourrait déjà adopter dans un premier temps.

Si en plus l'usager ne se rend pas compte de cette substitution et qu'il ne se souvient plus s'être loggué via FC la fois précédente, on le perd complètement.

L'alternative, comme le font par exemple ResearchGate ou GitHub, pourrait être de gérer une liste d'emails pour un compte, parmi lesquels une adresse primaire (ce qui n'est pas incompatible avec la notion de vérification du mail telle qu'employée actuellement dans A2 — donc vérification au sens de validation par une autorité tierce telle que FC).
Lors de la liaison FC :
- si l'adresse renvoyée par FC est déjà connue pour ce compte Publik, alors (dans l'optique de simplification des ces écrans de liaison, qui dépasse le cadre de ce ticket) on zappe l'écran de liaison.

C'est déjà ce qu'on fait, donc ok.

- si l'adresse n'est pas connue, on la présent à l'usager et on lui demande s'il souhaite la définir comme adresse primaire (en lui présentant aussi la liste des adresses déjà connues parmi lesquelles l'adresse primaire en cours), ce qui ne l'empêche pas de se logguer avec l'une des autres adresses connues par la suite.

En gros c'est pareil que maintenant (techniquement) il n'y a que le wording qui change, ok aussi. En fait je ne comprends pas bien l'histoire de liste d'email, on peut tout faire sans; mais j'aime bien aussi, juste en vrai il n'y a que la primaire qui sera prise en compte par le reste de Publik, mais ça me va de rendre possible d'enregistrer plusieurs emails au cas où pour se protéger, mais les secondaires on a même pas besoin de les valider.

Benjamin Dauvergne a écrit :

qu'on pourrait déjà adopter dans un premier temps.

J'ignorais complètement cette config, je vais regarder ça.

C'est déjà ce qu'on fait, donc ok.

En fait le consensus était plutôt d'abandonner complètement l'appairage automatique. Ma remarque était mal formulée et aurait dû être quelque chose comme “Si l'adresse renvoyée par FC et déjà connue et que l'appairage a déjà été fait par le passé […]"

En gros c'est pareil que maintenant (techniquement) il n'y a que le wording qui change, ok aussi. En fait je ne comprends pas bien l'histoire de liste d'email, on peut tout faire sans; mais j'aime bien aussi, juste en vrai il n'y a que la primaire qui sera prise en compte par le reste de Publik, mais ça me va de rendre possible d'enregistrer plusieurs emails au cas où pour se protéger, mais les secondaires on a même pas besoin de les valider.

Et bien il me semblait que dans les cas où on appaire ou on retrouve la liaison déjà effectuée, l'adresse email est écrasée par celle venant de FC sans que l'usager s'en aperçoive.
Et, si on part du principe qu'on ne fait pas confiance au FI pour la validité des emails et qu'un email retourné par le FI et sur le point d'être défini comme l'un des emails secondaires peut servir à retrouver un mot de passe perdu, il faut valider, d'abord à partir de l'email primaire connu pour vérifier que c'est bien l'usager qu'on a bien en face, et valider en suite l'email secondaire pour s'assurer que l'usager le détient bien.

Paul Marillonnet a écrit :

En fait le consensus était plutôt d'abandonner complètement l'appairage automatique. Ma remarque était mal formulée et aurait dû être quelque chose comme “Si l'adresse renvoyée par FC et déjà connue et que l'appairage a déjà été fait par le passé […]"

Oui c'est mon avis aussi, mais on peut aider pas mal quand même sur la base du mail, voir plus bas.

En gros c'est pareil que maintenant (techniquement) il n'y a que le wording qui change, ok aussi. En fait je ne comprends pas bien l'histoire de liste d'email, on peut tout faire sans; mais j'aime bien aussi, juste en vrai il n'y a que la primaire qui sera prise en compte par le reste de Publik, mais ça me va de rendre possible d'enregistrer plusieurs emails au cas où pour se protéger, mais les secondaires on a même pas besoin de les valider.

Et bien il me semblait que dans les cas où on appaire ou on retrouve la liaison déjà effectuée, l'adresse email est écrasée par celle venant de FC sans que l'usager s'en aperçoive.
Et, si on part du principe qu'on ne fait pas confiance au FI pour la validité des emails et qu'un email retourné par le FI et sur le point d'être défini comme l'un des emails secondaires peut servir à retrouver un mot de passe perdu, il faut valider, d'abord à partir de l'email primaire connu pour vérifier que c'est bien l'usager qu'on a bien en face, et valider en suite l'email secondaire pour s'assurer que l'usager le détient bien.

Ou simplement l'ignorer par défaut lors d'une liaison ou d'une connexion (ici j'ai l'impression qu'on confond les deux) comme la configuration CUT plus haut le permet ; pour une création de compte je dirai qu'il faut simplement revalider le mail avec l'usager (on sait que c'est lui c'est déjà ça). Donc 3 cas :

• première connexion : si l'email est connu on le dit à la personne et on lui propose de s'authentifier avec ce compte, ce n'est plus automatique (mais au moins on aide la personne en lui indiquant qu'on sait qu'elle a déjà un compte) mais aidé; là elle choisit :
  • création d'un nouveau compte : on présente l'email reçu, si cette adresse était inconnue on demande à la personne de la confirmer ou d'en choisir une autre :
    • si elle accepte l'email FC on l'enregistre sans validation et continue, on a juste ajouté un click à la procédure d'enregistrement,
    • si elle en propose une autre, on rentre dans un enregistrement pseudo-classique avec envoie d'un mail de validation, sauf qu'au passage on crée aussi une liaison FC et on ne demande pas de définir un mot de passe,
  • authentification avec un compte existante (celui indiqué ou un autre) : en cas de réussite on ne touche pas à l'email présent sur le compte, dans le futur si on gère ces emails secondaires on pourra demander à la personne si elle souhaite ajouter ce mail à sa liste d'email secondaire (sans validation), si c'est l'email de son comptable c'est son problème,
• connexions suivantes via FC : on ne touche pas au mail si il change ; dans le futur avec ces histoires d'email secondaire on pourra proposé de l'enregistrer (même cas qu'au dessus).

Clairement la gestion d'un ou plusieurs mails secondaires est assez orthogonale du problème en question.