Produits Entr'ouvert » Authentic 2

Mais ça arrive quand, ça ? Un ordinateur qui décide tout seul de changer de casse ?

Constaté dans #27039. L'uid de l'usager était en minuscules, ensuite changé en majuscules dans l'annuaire (à priori).

Oui mais à ce compte-là, on pourrait aussi dire de ne pas faire gaffe aux points, sur l'idée que dans l'annuaire frederic.peters pourrait être remplacé par fredericpeters. Et puis il pourrait être remplacé par fpeters et donc il faudrait gérer aussi un changement qui verrait un nom remplacé par une initiale. Puis gérer la possibilité que les initiales du prénom soient déplacées à fin. Etc.

Plus simple de figer la règle comme quoi la clé ne doit pas bouger.

Frédéric Péters a écrit :

Plus simple de figer la règle comme quoi la clé ne doit pas bouger.

Oui. Ca a bougé pour une raison sur #27039, c'est ça qu'il faut bien comprendre avant de voir si on doit proposer un contournement.

S'il fallait un patch, ça serait d'avoir dans la config du backend LDAP la possibilité de dire un filtre Django (ou autre mécanisme) à appliquer sur l'id pour le rendre "unique même quand l'annuaire fait du n'importe quoi" (genre ici, {{id|lower}})

Il y a quand même une logique, la plupart du temps on construit l'external_id à partir de sAMAccountName ou uid qui sont toux deux insensibles à la casse d'après les schémas LDAP:

#olcAttributeTypes:·(·0.9.2342.19200300.100.1.1¶
#→      NAME·(·'uid'·'userid'·)¶
#→      DESC·'RFC1274:·user·identifier'¶
#→      EQUALITY·caseIgnoreMatch¶
#→      SUBSTR·caseIgnoreSubstringsMatch¶
#→      SYNTAX·1.3.6.1.4.1.1466.115.121.1.15{256}·)¶
#¶

Ce n'est pas déconnant de les comparer en ignorant la casse (par contre un point en plus ce n'est pas le même uid, qu'ils aillent manger du foin).

Ma suggestion par Jabber à Serghei c'était non pas de modifier le comportement par défaut mais j'ajouter une option "external_id_use_iexact": False qui permettra d'indiquer quand on veut les rechercher via __iexact plutôt que par la recherche normale __excact.

Benjamin Dauvergne a écrit :

Il y a quand même une logique, la plupart du temps on construit l'external_id à partir de sAMAccountName ou uid qui sont toux deux insensibles à la casse d'après les schémas LDAP: (...)
Ma suggestion par Jabber à Serghei c'était non pas de modifier le comportement par défaut mais j'ajouter une option "external_id_use_iexact": False qui permettra d'indiquer quand on veut les rechercher via __iexact plutôt que par la recherche normale __excact.

D'accord avec ça. Je découvre d'ailleurs que le format de sAMAccountName dans AD est aussi insensible à la casse, c'est un objet String(Unicode) dans AD, et https://docs.microsoft.com/fr-fr/windows/desktop/ADSchema/s-string-unicode

Thomas Noël a écrit :

D'accord avec ça. Je découvre d'ailleurs que le format de sAMAccountName dans AD est aussi insensible à la casse, c'est un objet String(Unicode) dans AD, et https://docs.microsoft.com/fr-fr/windows/desktop/ADSchema/s-string-unicode

Quasiment tous les identifiants sont insensibles à la casse sous windows, sans compter les milliers de types de chaîne différents.

On parlait plus haut « ajouter une option "external_id_use_iexact" » , je pense que ça reste nécessaire pour les vrais annuaires pas débiles. Ou bien ?

Ça roule. Une option bizarre de moins, c'est bien aussi :)

Il faut mettre les numéro des tickets en début du nom de branche, ça affiche le statut ici.

C'est ce que je cherchais, merci.
Je saurais pour les prochaines fois.

Le build a foiré mais c'est un test de perf à la con dans la partie RBAC, tu peux ignorer.