Evolution #141
ferméGestion d'un préfixe facultatif sur les identifiants
100%
Description
Les identifiants doivent être uniques sur l'ensemble de la plate-forme.
Néanmoins, si par exemple certains comptes sont créés/synchronisés avec des systèmes externes propre aux EPN, il peut être souhaitable que les usagers disposent du même identifiant. Cela peut poser problème avec la contrainte d'unicité globale.
Une solution pour éviter ce risque est d'ajouter un préfixe aux identifiants. Seuls ceux concernés, càd issue d'une synchronisation avec une autre base d'un EPN, seront à préfixer. Si ce préfixe permet de garantir l'unicité dans la base de ProxyEPN, il faut cependant qu'il soit transparent à l'usage : l'usager ne doit pas avoir besoin de le connaitre/saisir.
Le système d'authentification principalement doit être assoupli en ce sens (recherche du compte avec ou sans le préfixe).
Dans les faits, ce sytème revient à permettre plusieurs comptes utilisant un même identifiant (en excluant le préfixe). A l'authentification par exemple, plusieurs comptes avec différents préfixes pourront correspondre : c'est le test sur le mot de passe qui sera alors déterminent pour trouver le compte de l'usager.
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
- Statut changé de In Progress à Résolu
- Assigné à mis à Grégory MARIGOT - TEICEE
- % réalisé changé de 0 à 100
Principe¶
La syntaxe pour le préfixe est d'utiliser le caractère '+' comme séparateur (celui-ci n'étant normalement pas permis dans l'identifiant).
Pour l'authentification, la recherche du compte se fait toujours en comparant avec exactitude l'identifiant saisi aux identifiants stockés (pouvant contenir un préfixe). Mais dans un second temps, si aucun compte n'est trouvé, une recherche est effectué sans tenir compte des préfixes (LIKE '%+'.$username).
Le principe des préfixes peut générer des pseudo-doublons : en interne les identifiants sont toujours bien tous différents, mais si on omet la présence des préfixes, la partie restante n'est pas forcément unique. Si cela permet d'importer sans ce soucier des identifiants externes en garantissant l'unicité globale, pouvoir rendre transparent leur présence aux utilisateurs peut produire ces pseudo-doublons qui devront alors être distinguer grâce aux mots de passe.
Exemple :¶
On peut avoir dans la base 3 utilisateurs différents avec en identifiants : greg, test+greg, crm2950+greg
Ces 3 identifiants sont bien sûr utilisables tels quels pour s'authentifier, mais les utilisateurs peuvent aussi n'utiliser que greg tous les 3 pour se connecter à leur compte respectif (celui qui aura le bon mot de passe).
Masquage :¶
A l'affichage, un identifiant peut être présenté avec ou sans son éventuel préfixe.Par défaut, les règles suivantes s'appliquent en fonction du rôle de l'utilisateur :
- superadmin : les préfixes sont toujours affichés
- animateur et coordinateur : selon le choix d'une option globale de l'application
- usager et visiteur : les préfixes sont toujours masqués
De plus dans certains cas, le code de l'application peut forcer l'affichage ou le masquage des préfixes selon la situation (présence dans les exports, masquage sur les badges...)
A l'édition de l'identifiant (maintenant possible, cf #140) si le préfixe est masquée, il sera automatiquement ajouté avant la sauvegarde (uniquement s'il était présent).
L'option pour déterminer si les animateurs et coordinateurs ont accès au préfixe ou non se trouve dans le fichier app.yml :
all:
options:
show_login_prefix: false
Synchronisation¶
Un rôle important repose sur la présence des préfixes dans les identifiants : la synchronisation des fiches usagers.
Vu que l'existence des préfixes est essentiellement intéressant pour la gestion d'imports de comptes, son usage sera exclusivement réservé à ces cas. Autrement dit, il n'est pas souhaitable que l'on puisse saisir des préfixes manuellement via l'interface web. Ce sont les opérations d'import et de synchronisation qui se chargeront d'en spécifier.
Partant de ce principe, la présence d'un préfixe dans un identifiant est utilisée comme indicateur de compte synchronisé. Un tel compte peut alors avoir des contraintes sur son édition : une liste de champs protégés peut être spécifiée. Un champs protégé est supposé mis à jour depuis une source externe et son édition dans l'interface web est impossible. Par contre l'édition des autres champs de la fiche est toujours permise.
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 11 ans
- Statut changé de Résolu à Fermé