Support #5232
fermé
Synchronisation de groupe inopérante sur attribut LDAP
100%
Description
Les groupes synchronisés sur un attribut LDAP ne se remplissent pas malgré la présence d'utilisateurs répondant à cette règle.
Mis à jour par Cécile Bonin il y a presque 11 ans
- Statut changé de New à Qualified
Constaté chez un client avec MS Active Directory et l'attribut objectGUID comme clé d'identification unique des utilisateurs.
Je joins les traces en mode Debug sur la messagerie support.
On voit dans les traces que les 8 utilisateurs répondant à la règle DC_title=Assistant\28e\29 de pôle sont bien récupérés dans l'Active Directory.
Par contre, j'ai testé la requête exécutée ligne 191 dans la table des user Silverpeas.
Cette requête renvoit 0 résultat car les valeurs des id spécifiques contenant des back slash ne sont pas doublés.
Ceci est du à la correction qui a été faite en V5.12.4 par rapport au bug #4388 : la correction avait été de supprimer le doublage des back slah.
Il semble que dans un cas, il soit nécessaire de ne pas les doubler et que dans celui-ci, il le faille.
Mis à jour par Cécile Bonin il y a presque 11 ans
En fait la différence viendrait de la version de postgreSQL : en 8.x, il semble nécessaire de doubler les back slash dans la requête et en 9.x, non.
Mis à jour par David Lesimple il y a presque 11 ans
je confirme (http://tapoueh.org/blog/2011/08/18-echappements-de-chaine.html)
j'ai rencontré le problème pour les requetes de renommage de noms de fichiers avant une migration JCR.
Mis à jour par Cécile Bonin il y a presque 11 ans
Oui, il faut utiliser la syntaxe de chaîne d'échappement (E'...').
Il faut aussi doubler les back slahs.
ex :
select id, specificId, domainId, login, firstName, lastName, loginMail, email, accessLevel, loginQuestion, loginAnswer, creationDate, saveDate, version, tosAcceptanceDate, lastLoginDate, nbSuccessfulLoginAttempts, lastLoginCredentialUpdateDate, expirationDate, state, stateSaveDate
from ST_User
where domainId = 1 and specificId IN
(E'\\\\c5\\\\e5\\\\df\\\\b2\\\\df\\\\71\\\\ba\\\\46\\\\84\\\\cf\\\\d8\\\\dd\\\\f1\\\\44\\\\7d\\\\e4')
J'ai testé cette requête qui marche dans les 2 versions postgreSQL 8.x et postgreSQL 9.x.
Mis à jour par Nicolas Eysseric il y a plus de 10 ans
- Statut changé de Qualified à Feedback
Dans Silverpeas-Core, nous ne devons pas faire de traitement spécifique à une base de données.
Le problème décrit ici doit être contourné par l'utilisation de PostgreSQL 9.x.
De plus, dans la série 8, actuellement seul PostgreSQL 8.4 est encore supporté. Mais pas pour longtemps, car la fin du support de cette version est programmée pour ce mois-ci justement : http://www.postgresql.org/support/versioning
Mis à jour par Nicolas Eysseric il y a environ 10 ans
- Tracker changé de Bug à Support
- Statut changé de Feedback à Closed
- % réalisé changé de 0 à 100
Problème limité à l'usage de PostgreSQL 8.x ET Active Directory.
PostgreSQL 8 ne doit plus être utilisé. La version 9 doit l'être...