Je n’ai rien ni dans les logs tomcat ni Simplicité 
Pas moyen de débugger le code de choix du mode d’authentification ?
En l’état à chaque fois qu’un user se déconnecte, il tombe sur l’erreur 500 :-/
Il n’y a que nous qui pouvons debugger le code du socle, or cf. cette réponse: Problème de redirection au logout - #4 by david on ne reproduit pas le pb décrit avec une authent LDAP.
Il y a forcément un truc particulier dans votre cas mais sans aucun élément précis pour cerner ce qu’il se passe il nous est compliqué d’investiguer plus avant.
PS: Dans une réponse de Julien Roy il y a cette phrase: “L’erreur disparait si on ajoute une nouvelle méthode d’authentification, car on est redirigé correctement vers l’écran permettant le choix de l’authentification”, je crois avoir testé avec une ident LDAP seule sans pb mais ça vaut la peine de vérifier ça chez vous: est-ce que le pb se produit toujours en laissant l’authent interne mais en la mettant "visible": false
Elle est visible false de base. Si je mets true, je suis redirigée vers la page de choix et je n’ai pas le problème
Et si je mets OKTA seul je suis correctement redirigée vers le login OKTA donc c’est un problème spécifique à la redirection LDAP seul.
OK le pb est peut être lié au fait de n’avoir que le provider LDAP. Il me semble pourtant avoir vérifié. Je le referai et je te tiendai au courant.
En attendant, que se passe-t-il avec authent interne non visible et authent LDAP ?
[
{ "name": "simplicite", "type": "internal", "visible": false },
{ "name": "ldap", "type": "ldap", "visible": true, "sync": false }
]
Le problème se produit justement avec autent interne non visible.
En résumé :
- interne non visible, LDAP visible → erreur 500
- interne visible, LDAP visible → OK
- interne non visible, OKTA visible → OK
OK vu, un test sur la session manquait et ça pouvait finir en NPE quand celle-ci n’était pas initialisée.
Ce sera corrigé en 5.3.10
1 Like
Testé et validé, merci !