Recherche d'utilisateurs dans Esup-ECM

  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:8bf7209f823625e875c6510fabd6a12c' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\"><!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n<html>\n <head>\n <meta content=\"text/html; charset=ISO-8859-1\"\n http-equiv=\"Content-Type\">\n </head>\n <body text=\"#000000\" bgcolor=\"#ffffff\">\n <font size=\"-1\"><font face=\"Verdana\">Bonjour,<br>\n <br>\n Vous &ecirc;tes bien pass&eacute;e par l\'installation quick-install et non\n express ?</div>', created = 1507754899, expire = 1507841299, headers = '', serialized = 0 WHERE cid = '4:8bf7209f823625e875c6510fabd6a12c' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:8bf7209f823625e875c6510fabd6a12c' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\"><!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n<html>\n <head>\n <meta content=\"text/html; charset=ISO-8859-1\"\n http-equiv=\"Content-Type\">\n </head>\n <body text=\"#000000\" bgcolor=\"#ffffff\">\n <font size=\"-1\"><font face=\"Verdana\">Bonjour,<br>\n <br>\n Vous &ecirc;tes bien pass&eacute;e par l\'installation quick-install et non\n express ?</div>', created = 1507754899, expire = 1507841299, headers = '', serialized = 0 WHERE cid = '4:8bf7209f823625e875c6510fabd6a12c' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:27ed67f99c0c457273141a9734fd8467' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\"> Bonjour Julien,</p>\n<p>J\'ai passé du temps hier a bien décortiquer le mécanisme nuxeo afin de<br />\ncomprendre pourquoi on a ces différentes requêtes LDAP.</p>\n<p>Pour le moment je n\'ai fait ce travail que sur les users (3 premières<br />\nrequêtes) et pas les groupes (4eme requête).</p>\n<p>Déjà tu as un<br />\n\"(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)\"<br />\n--> J\'imagine que pour ça tu as modifié<br />\ndefault-ldap-users-directory-bundle.xml pour définir la balise<br />\n<searchFilter></p>\n<p>Ce qui faut comprendre c\'est que nuxeo utilise un UserService qui lui<br />\nmême s\'appuie sur des Directories qui peuvent être LDAP, SQL ou autres.</p>\n<p>Ici le UserService demande au Directories :<br />\n- dit moi qui a un \"username\" qui vaut commence par \"robb\"<br />\n- dit moi qui a un \"firstName\" qui vaut commence par \"robb\"<br />\n- dit moi qui a un \"lastName\" qui vaut commence par \"robb\"</p>\n<p>Le fait que le UserService face trois demande fait que l\'on a trois<br />\ndemandes LDAP et pas une seule avec un filtre LDAP avec des \"ou\" comme<br />\non pourrait s\'y attendre.</p>\n<p>Ensuite on peut se demander pourquoi le UserService fait ces trois<br />\ndemandes là et pas d\'autres.</p>\n<p>En fait nuxeo propose un point d\'extension qui permet de définir quels<br />\nsont les attributs qui sont requêtés. cf.<br />\n<a href=\"http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionPoint/org.nuxeo.ecm.platform.usermanager.UserService--userManager\" title=\"http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionPoint/org.nuxeo.ecm.platform.usermanager.UserService--userManager\">http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionP...</a><br />\net utilisation de \"users/searchFields\".</p>\n<p>J\'ai donc regardé où ce point d\'extension était utilisé et je ne l\'ai<br />\npas trouvé ! En fait, qu\'on le définisse ou pas nuxeo ajoute toujours<br />\n\"username\", \"firstName\"et \"lastName\" (sauf si on positionne<br />\n\"users/searchFields@append\" à false dans le point d\'extension).</p>\n<p>Ensuite on peut se demander comment le \"username\" devient \"uid\" (de même<br />\npour \"firstName\"et \"lastName\") --> C\'est fonction du fichier<br />\ndefault-ldap-users-directory-bundle.xml livré avec ESUP-ECM qui précise :<br />\n<fieldMapping name=\"username\">uid</fieldMapping><br />\n<fieldMapping name=\"firstName\">givenName</fieldMapping><br />\n<fieldMapping name=\"lastName\">sn</fieldMapping></p>\n<p>Enfin pourquoi on a toujours (uid=*) dans le filtre ? --> C\'est en dur<br />\ndans le code nuxeo et il y a un commentaire pour dire que c\'est lié à<br />\nune demande de support (Cf. <a href=\"https://jira.nuxeo.org/browse/NXP-2461\" title=\"https://jira.nuxeo.org/browse/NXP-2461\">https://jira.nuxeo.org/browse/NXP-2461</a>)</p>\n<p>Donc pour les questions de perfs il faut regarder si les champs qui sont<br />\nrequêtés sont bien indexés dans ton LDAP (attention au type de requête<br />\nqui est de type commence par)</p>\n<p>Éventuellement tu peux utiliser le point d\'extension afin de préciser<br />\nles champs sur lesquels tu veux faire la/les requêtes en :<br />\n- utilisant \"append=false\" si tu ne veux plus utiliser les requêtes par<br />\ndéfaut de nuxeo<br />\n- utilisant les sous-balises substringMatchSearchField ou<br />\nexactMatchSearchField de users/searchFields suivant que tu veux faire de<br />\nrequêtes de type substring ou pas</p>\n<p>A+</p>\n<p>Le 20/07/2010 09:38, Julien Troubat a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n><br />\n> Nous avons remarqué que la recherche d\'utilisateurs dans Esup-ECM<br />\n> était très longue, voir trop longue (6 secondes) et parfois même<br />\n> n\'aboutissait pas.<br />\n><br />\n> EN traçant les requêtes sur le serveur LDAP on se rend compte qu\'il<br />\n> fait des recherches sur plusieurs critères la plupart du temps inutile<br />\n> (uid, cn, givenname).<br />\n><br />\n> Exemple :<br />\n><br />\n> Jul 19 17:04:33 akira slapd[2245]: conn=86125 op=14 SRCH<br />\n> base=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\n> filter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(uid=robb*))\"<br />\n><br />\n> Jul 19 17:04:36 akira slapd[2245]: conn=86125 op=15 SRCH<br />\n> base=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\n> filter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(givenName=robb*))\"<br />\n><br />\n> Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=16 SRCH<br />\n> base=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\n> filter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(sn=robb*))\"<br />\n><br />\n> Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=17 SRCH<br />\n> base=\"ou=groups,dc=univmed,dc=fr\" scope=2 deref=3<br />\n> filter=\"(&amp;(&amp;(&amp;(|(objectClass=groupOfNames)(objectClass=groupOfURLs)))(cn=*))(cn=robb*))\"<br />\n><br />\n><br />\n> Y a-t\'il un moyen de modifier la manière dont il effectue la recherche<br />\n> pour qu\'il se concentre sur le sn. De plus pourquoi faire un filtre<br />\n> avec cn=* + cn=robb*. Sachant que la recher demandée est robb.<br />\n><br />\n><br />\n> Merci d\'avance, bonne journée.<br />\n></div>\n</blockquote>\n</div>\n', created = 1507754900, expire = 1507841300, headers = '', serialized = 0 WHERE cid = '4:27ed67f99c0c457273141a9734fd8467' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:938fd511e621f700010c37f34e6f5fc9' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>Nous avons remarqué que la recherche d\'utilisateurs dans Esup-ECM était<br />\ntrès longue, voir trop longue (6 secondes) et parfois même n\'aboutissait<br />\npas.</p>\n<p>EN traçant les requêtes sur le serveur LDAP on se rend compte qu\'il fait<br />\ndes recherches sur plusieurs critères la plupart du temps inutile (uid,<br />\ncn, givenname).</p>\n<p>Exemple :</p>\n<p>Jul 19 17:04:33 akira slapd[2245]: conn=86125 op=14 SRCH<br />\nbase=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\nfilter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(uid=robb*))\" </p>\n<p>Jul 19 17:04:36 akira slapd[2245]: conn=86125 op=15 SRCH<br />\nbase=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\nfilter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(givenName=robb*))\" </p>\n<p>Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=16 SRCH<br />\nbase=\"ou=people,dc=univmed,dc=fr\" scope=1 deref=3<br />\nfilter=\"(&amp;(&amp;(&amp;(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(sn=robb*))\" </p>\n<p>Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=17 SRCH<br />\nbase=\"ou=groups,dc=univmed,dc=fr\" scope=2 deref=3<br />\nfilter=\"(&amp;(&amp;(&amp;(|(objectClass=groupOfNames)(objectClass=groupOfURLs)))(cn=*))(cn=robb*))\" </p>\n<p>Y a-t\'il un moyen de modifier la manière dont il effectue la recherche<br />\npour qu\'il se concentre sur le sn. De plus pourquoi faire un filtre avec<br />\ncn=* + cn=robb*. Sachant que la recher demandée est robb.</p>\n<p>Merci d\'avance, bonne journée.</p>\n<p>--<br />\nTROUBAT Julien<br />\nUFR : Pharo<br />\nService : DOSI Pharo<br />\nTéléphone : 04 91 39 66 52<br />\nUniversité de la Méditerranée<br />\nJardin du Pharo<br />\n58 bd Charles Livon<br />\n13284 Marseille cedex 07</p>\n</div>\n', created = 1507754901, expire = 1507841301, headers = '', serialized = 0 WHERE cid = '4:938fd511e621f700010c37f34e6f5fc9' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
2 messages / 0 nouveaux
Dernière contribution
raymondbourges
Recherche d'utilisateurs dans Esup-ECM
Bonjour Julien,

J'ai passé du temps hier a bien décortiquer le mécanisme nuxeo afin de
comprendre pourquoi on a ces différentes requêtes LDAP.

Pour le moment je n'ai fait ce travail que sur les users (3 premières
requêtes) et pas les groupes (4eme requête).

Déjà tu as un
"(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)"
--> J'imagine que pour ça tu as modifié
default-ldap-users-directory-bundle.xml pour définir la balise

Ce qui faut comprendre c'est que nuxeo utilise un UserService qui lui
même s'appuie sur des Directories qui peuvent être LDAP, SQL ou autres.

Ici le UserService demande au Directories :
- dit moi qui a un "username" qui vaut commence par "robb"
- dit moi qui a un "firstName" qui vaut commence par "robb"
- dit moi qui a un "lastName" qui vaut commence par "robb"

Le fait que le UserService face trois demande fait que l'on a trois
demandes LDAP et pas une seule avec un filtre LDAP avec des "ou" comme
on pourrait s'y attendre.

Ensuite on peut se demander pourquoi le UserService fait ces trois
demandes là et pas d'autres.

En fait nuxeo propose un point d'extension qui permet de définir quels
sont les attributs qui sont requêtés. cf.
http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionP...
et utilisation de "users/searchFields".

J'ai donc regardé où ce point d'extension était utilisé et je ne l'ai
pas trouvé ! En fait, qu'on le définisse ou pas nuxeo ajoute toujours
"username", "firstName"et "lastName" (sauf si on positionne
"users/searchFields@append" à false dans le point d'extension).

Ensuite on peut se demander comment le "username" devient "uid" (de même
pour "firstName"et "lastName") --> C'est fonction du fichier
default-ldap-users-directory-bundle.xml livré avec ESUP-ECM qui précise :
uid
givenName
sn

Enfin pourquoi on a toujours (uid=*) dans le filtre ? --> C'est en dur
dans le code nuxeo et il y a un commentaire pour dire que c'est lié à
une demande de support (Cf. https://jira.nuxeo.org/browse/NXP-2461)

Donc pour les questions de perfs il faut regarder si les champs qui sont
requêtés sont bien indexés dans ton LDAP (attention au type de requête
qui est de type commence par)

Éventuellement tu peux utiliser le point d'extension afin de préciser
les champs sur lesquels tu veux faire la/les requêtes en :
- utilisant "append=false" si tu ne veux plus utiliser les requêtes par
défaut de nuxeo
- utilisant les sous-balises substringMatchSearchField ou
exactMatchSearchField de users/searchFields suivant que tu veux faire de
requêtes de type substring ou pas

A+

Le 20/07/2010 09:38, Julien Troubat a écrit :

> Bonjour,
>
> Nous avons remarqué que la recherche d'utilisateurs dans Esup-ECM
> était très longue, voir trop longue (6 secondes) et parfois même
> n'aboutissait pas.
>
> EN traçant les requêtes sur le serveur LDAP on se rend compte qu'il
> fait des recherches sur plusieurs critères la plupart du temps inutile
> (uid, cn, givenname).
>
> Exemple :
>
> Jul 19 17:04:33 akira slapd[2245]: conn=86125 op=14 SRCH
> base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
> filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(uid=robb*))"
>
> Jul 19 17:04:36 akira slapd[2245]: conn=86125 op=15 SRCH
> base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
> filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(givenName=robb*))"
>
> Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=16 SRCH
> base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
> filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(sn=robb*))"
>
> Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=17 SRCH
> base="ou=groups,dc=univmed,dc=fr" scope=2 deref=3
> filter="(&(&(&(|(objectClass=groupOfNames)(objectClass=groupOfURLs)))(cn=*))(cn=robb*))"
>
>
> Y a-t'il un moyen de modifier la manière dont il effectue la recherche
> pour qu'il se concentre sur le sn. De plus pourquoi faire un filtre
> avec cn=* + cn=robb*. Sachant que la recher demandée est robb.
>
>
> Merci d'avance, bonne journée.
>

julientroubat
Bonjour,

Nous avons remarqué que la recherche d'utilisateurs dans Esup-ECM était
très longue, voir trop longue (6 secondes) et parfois même n'aboutissait
pas.

EN traçant les requêtes sur le serveur LDAP on se rend compte qu'il fait
des recherches sur plusieurs critères la plupart du temps inutile (uid,
cn, givenname).

Exemple :

Jul 19 17:04:33 akira slapd[2245]: conn=86125 op=14 SRCH
base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(uid=robb*))"

Jul 19 17:04:36 akira slapd[2245]: conn=86125 op=15 SRCH
base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(givenName=robb*))"

Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=16 SRCH
base="ou=people,dc=univmed,dc=fr" scope=1 deref=3
filter="(&(&(&(|(eduPersonAffiliation=student)(eduPersonAffiliation=faculty)(eduPersonAffiliation=employee)(eduPersonAffiliation=researcher)))(uid=*))(sn=robb*))"

Jul 19 17:04:39 akira slapd[2245]: conn=86125 op=17 SRCH
base="ou=groups,dc=univmed,dc=fr" scope=2 deref=3
filter="(&(&(&(|(objectClass=groupOfNames)(objectClass=groupOfURLs)))(cn=*))(cn=robb*))"

Y a-t'il un moyen de modifier la manière dont il effectue la recherche
pour qu'il se concentre sur le sn. De plus pourquoi faire un filtre avec
cn=* + cn=robb*. Sachant que la recher demandée est robb.

Merci d'avance, bonne journée.

--
TROUBAT Julien
UFR : Pharo
Service : DOSI Pharo
Téléphone : 04 91 39 66 52
Université de la Méditerranée
Jardin du Pharo
58 bd Charles Livon
13284 Marseille cedex 07

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur « Enregistrer les paramètres » pour activer vos changements.
Sujet clos