Bonjour,
Je souhaiterais pouvoir, en cas d’échec de connexion OIDC (user non déclaré dans OKTA), connecter l’utilisateur avec un profil par défaut en lecture seule.
Y a-t-il possibilité de gérer ce cas ?
Nous avons l’erreur suivante générée com.simplicite.webapp.servlets.OAuth2Servlet|doGet||Event: No OpenIDConnect okta code parameter
Je voudrais pouvoir l’identifier et en faire quelque chose, mais je ne sais pas où …
Merci d’avance pour votre aide !
Emmanuelle
On parle de quelle version de Simplicité ? Je pose la question car en v6 il y a un hook de customisation d’erreur (customErrorResponse) qui permet peut être de faire des choses en fct de l’erreur en question (ce hook n’est pas spécifique aux erreurs d’ident/authent = on parle de toutes les erreurs de la plateforme donc à implémenter en ciblant les cas d’erreurs précis et en appelant le super pour le reste)
Attention toutefois:
un message d’erreur du type “No OpenIDConnect okta code parameter” ne signifie pas forcément que le user n’a pas été identifié par l’IdP, cela peut avoir d’autres causes comme une tentative de “piratage” ou autre cas tordu => cela signifie uniquement que l’appel de la callback se fait sans le paramètre requis code
une approche où un user demande à s’identifier via un IdP, puis où l’IdP répond qu’il ne connait pas cette personne, et qu’on décide malgré tout de le connecter sur un user générique ne semble pas une approche très souhaitable => ça devrait être plutôt à l’IdP sollicité de gérer ce “fallback” sur un user technique, ou alors il faudrait implémenter un pseudo provider “Connectez vous en tant que user anonyme” distinct du provider “Authentifiez vous avec OKTA”, ce pseudo provider étant configuré (via le parseAuth) pour connecter un user générique (ainsi un user qui se fait jeter par l’IdP reviendrait sur la page du choix du mode d’authent et indiquerait explicitement vouloir se connecter anonymement)
Nous sommes en 6.2, je vais regarder ce hook merci beaucoup.
Je suis d’accord pour le point 2, je vais voir avec l’IDP mais je ne crois pas qu’ils gèrent ce cas. On va voir pour proposer un workflow explicite proposant une connexion générique, ou au moins un lien vers la demande de création de compte. Aujourd’hui on a une 404 ce qui n’est pas très compréhensible pour les utilisateurs.
Je ne vois pas trop de raison pour qu’un IdP qui ne reconnait pas un user rappelle Simplicité… normalement en cas d’erreur d’identification ou d’authentification ça reste au niveau IdP jusqu’à ce que le user soit identifié ou abandonne.
Il faudrait regarder précisément les flux (onglet network du navigateur) pour voir la séquence précise d’appels qui aboutit sur ce “404”
On parle de quelle révision exacte de la 6.2 ? Je pose la question car on a amélioré récemment la remontée des erreurs (notamment pour le hook customErrorResponse) donc dans tous les cas il faut être à jour (la 6.2 actuelle est la 6.2.8 releasée le 25/04/25)
D’accord je vais débugger, je pensais aussi que ça n’allait pas jusqu’à Simplicité.
On est en 6.2.6, je vais mettre à jour.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.