Erreur à l'affichage d'un formulaire sur objet mappé LDAP

Request description

Bonjour,

J’ai un objet mappé sur notre annuaire avec une connexion LDAP.

Je ne parviens pas à afficher une ligne de cet objet en formulaire, mais l’affichage en liste fonctionne.
Il me semble que cela se produit depuis la migration en 5.2.
J’ajoute les logs ci-dessous.

Pouvez vous m’aider ?
Merci d’avance !
Emmanuelle

Steps to reproduce

1.Configurer un objet sur service-ldap
2.Afficher en liste
3. Cliquer sur une ligne

Technical information

Instance /health
[Platform]
Status=OK
Version=5.2.26
BuiltOn=2022-12-20 22:00
Simplicité logs
2023-01-18 14:05:32,273|SIMPLICITE|ERROR||http://simplicite-dev-6c8f7449b5-nh4df:8080||ECORESV001|designer|com.simplicite.util.ObjectServiceLDAP|selectService||
    org.json.JSONException: JSONObject["uid"] not found.
     at org.json.JSONObject.get(JSONObject.java:580)
     at org.json.JSONObject.getString(JSONObject.java:867)
     at com.simplicite.util.ObjectServiceLDAP.selectService(ObjectServiceLDAP.java:249)
     at com.simplicite.util.engine.ObjectManager.select(ObjectManager.java:1432)
     at com.simplicite.util.engine.ObjectDirect.select(ObjectDirect.java:366)
     at com.simplicite.util.ObjectDB.select(ObjectDB.java:984)
     at com.simplicite.util.tools.JSONTool.get(JSONTool.java:3012)
     at com.simplicite.webapp.ObjectJson.get(ObjectJson.java:285)
     at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:636)
     at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:102)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:779)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:62)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:49)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at com.simplicite.webapp.filters.HTTPHeadersFilter.doFilter(HTTPHeadersFilter.java:39)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:49)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:220)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:49)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:163)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
     at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
     at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
     at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
     at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891)
     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784)
     at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
     at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
     at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
     at java.base/java.lang.Thread.run(Thread.java:833)
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

J’ai fait le test avec un objet LDAP sur ue 5.2 à jour (5.2.27), je ne vois pas de pb à priori :

Liste:


Formulaire:

Avec:


Et les attributs qui mappent au niveau du nom phusique sur les attributs LDAP : cn, sn, givenName, mail, …

Ca doit être un problème dans mon paramétrage mais je ne peux pas débugger ObjectServiceLdap :frowning:
Une idée de comment peut survenir ce JSONObject[“uid”] not found ?

Ce message doit à priori vouloir dire que le record LDAP en question ne contient pas l’attribut uid, il faudrait vérifier directement dans le LDAP

Je ne sais pas trop comment ça se comporte si on configure un attribut de l’objet métier qui ne matche pas sur un attribut qui existe coté LDAP. Je vais regarder ce cas particulier.

Ca ne semble pas lui poser de pb:

avec
image
test n’étant pas un attribut des records LDAP en question.

EDIT:
Je pense que ça doit plutôt être un pb de “tuyauterie” avec le LDAP.

Une piste:

Dans le code de ObjectServiceLDAP (la classe helper qui fait les appels LDAP pour les objets de type service-ldap) l’attribut qui fait office de row ID par défaut est uid

“Par défaut” signifiant qu’on a pas explicitement déclaré un attribut comme row ID custom de l’objet.

A mon avis c’est ça le pb => votre objet n’a pas de row ID custom qui pointe sur un attribut du LDAP, du coup il utilise, par défaut, uid qui ne doit pas être un des attributs des records LDAP en question.

Sans un row ID unique explicite ou implicite (=uid) ça ne peut pas marcher, avoir quelque chose qui fait office de row ID étant obligatoire pour les objets Simplicité.

1 Like

Merci pour ces précisions, j’ai comme rowid custom un field mappé sur le uid


Pour l’affichage en liste, j’ai bien des résultats et je vois apparaître le uid dans la colonne correspondante.
Mais quand j’affiche une ligne j’ai un “no rowid found” et cette erreur dans les logs.

J’ai configuré mon objet de la même manière avec un attribut row ID custom pointant sur l’attribut LDAP uid (dans mon LDAP de test ces 2 attributs contiennent le username unique) et je n’ai pas constaté de pb.

Par contre, j’ai l’impression qu’en faisant pointer ce row ID custom sur un autre attribut LDAP unique (ex: cn dans mon cas) ça ne se passe pas bien (je vois alors ce message “No row found” à l’ouverture du formulaire), je vais creuser ce cas mais si j’ai bien suivi ce n’est pas votre cas.

Quoiqu’il en soit, pour tracker de plus près les requêtes/réponses LDAP il faut passer le log event DCORESV001 à “info”:

Non en effet j’ai mon row_id custom qui pointe sur uid.
Je vais activer ces traces et regarder, merci !

Vérification faite l’attribut row ID custom (ou implicitement uid) est utilisé pour construire le DN utilisé pour le select (= affichage le formulaire): get du <row ID>=..,<base DN paramétré sur l'objet>, on ne peut donc pas juste pointer sur un autre attribut LDAP comme le cn testé plus haut

Ca marche en liste car dans dans ce cas ça fait un search sur le base DN utilisant les attributs, mais ça ne marche pas au get qui se base sur le DN construit.

Je vais voir si ça peut être rendu plus malin, genre: ça tente d’abord un get sur le DN, puis si pas trouvé ça tente un search en vérifiant que ça ne ramène bien qu’un record (mais en cas de mauvais paramétrage avec un row ID non unique qui ramène N records, ça peut poser des pbs de perf, donc c’est peut être pas si malin)

Bref, dans votre cas est-ce que le DN du record à bien cette forme (uid=...,<base DN>) ?

Oui j’ai bien ce format.

Le clic sur la ligne échoue

Mais en liste cela fonctionne

Ce {} c’est étrange. Ca semble dire que le get sur le DN trouve un record mais qu’il n’arrive pas à en lire les attributs alors que dans le cas d’un search il y arrive… Le monde des LDAP est plein de mystères insondables…

Il faudrait tester en tapant directement sur le LDAP avec un outil ad hoc pour voir ce que ça fait en se connectant de la même manière (i.e. en anonymous), ex:
image

1 Like

D’accord merci beaucoup pour ces pistes, je vais faire des tests :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.