https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34755
Olivier Hubert <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- CC| |[email protected] --- Comment #2 from Olivier Hubert <[email protected]> --- I am reopening this bug as we noticed this exact problem happening with our only instance using SSO (and because Jonathan mentioned I should reopen the bug instead of creating a new one). I have reproduced the bug using Koha Testing Docker. Steps to reproduce, assuming you're using Koha Testing Docker, properly configured with Keycloak, although this might work using other configurations as well: 1. Open the OPAC 2. Log in with a regular Koha user, not using SSO. 3. In a private browser window, open the OPAC 4. log in using SSO with a different user account. 5. Notice that you get the error message "There was an error authenticating to external identity provider wrong_csrf_token" 6. Click on the "Log in with [...]" button, to log in again using SSO. 7. Notice that the user is immediately logged in. I have figured out part of the problem. It seems that when first loading the OPAC, the userenv variable is loaded with the latest session data instead of no data at all (e.g. anonymous). By adding a warning on line 224 of Koha/Token.pm, I can get the id on the first OPAC visit, as well as the id when returning from the SSO authentication. If I first login with a user named "koha", at step 2 of my steps to reproduce, I get something like this in plack-api-error.log: [2024/01/12 19:49:08] [WARN] The id for generating the CSRF token is: koha_16b598a250e8b2a9de9b3d94ec89d2c9 at /kohadevbox/koha/Koha/Token.pm line 224. [2024/01/12 19:49:13] [WARN] The id for generating the CSRF token is: anonymous_16b598a250e8b2a9de9b3d94ec89d2c9 at /kohadevbox/koha/Koha/Token.pm line 224. As you can see, the session id is the same, so the session is successfully saved and reused. But it seems the anonymisation happens after the userenv variable is used, and therefore the last used session username is used for generating the CSRF token instead of "anonymous". Note that getting "anonymous" on returning from authentication (step 5) is not guaranteed. On a very busy instance, I was able to get the last used session username instead. Also note that you can prevent the issue by reloading the OPAC page between step 3 and 4. If no one else has a more recent session, then the SSO login will work on the first try. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
