Nous ne reproduisons pas ce symptôme décrit sur une 5.3 à jour et avec une authent LDAP basique :
AUTH_PROVIDERS:
[
{ "name": "simplicite", "type": "internal" },
{ "name": "ldap", "type": "ldap", "sync": false }
]
et LDAP_AUTH_CONFIG:
{
"url": "ldap://localhost:389",
"dnpattern": "uid=[USERNAME],ou=People,dc=simplicite,dc=com"
}
Que vaut ce param système dans votre cas ? Auriez vous configuré d’autres params systèmes particuliers (ex: en *LDAP* et/ou en *URL*) ? etc.
Ce qui me semble spécifique/anormal dans votre onglet Network c’est les redirects 302 vers des URLs absolue alors que dans une séquence de logout LDAP nominale on a une suite de redirects relatifs:
Il faudrait voir si le reverse proxy / load balancer que vous avez peut être en amont de votre instance ne fait pas quelque chose de particulier. Typiquement s’il ne gère pas le transfert du hostname/port public à Tomcat ça peut avoir des effets inattendus… Avez vous bien cablé vos ports en fct de l’exposition en SSL ou pas (cf. Simplicité® documentation/90-operation/docker) ?
Il faudrait regarder de près les headers/contenus des différents appels d’URL, ex:
En tout cas la page qui finit en HTTP 500 doit surement générer au moins une trace d’erreur et/ou un stacktrace dans la log simplicité (dans /usr/local/tomcat/webapps/ROOT/WEB-INF/log/simplicite.log) et/ou sur la console Docker (en tout cas si vous n’avez pas customisé la config Log4J) car ce qui finit en HTTP 500 dans Simplicité ce sont les erreurs non prévues trappées dans le try/catch de premier niveau et à ce niveau il y a normalement systématiquement un AppLog.error(...)
PS: Mettez systématiquement des try/catch dans vos platform hooks pour mieux gérer un éventuel pb non prévu à ce niveau