https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34755 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #15 from David Cook <dcook@prosentient.com.au> --- Once again, I cannot reproduce this problem. After authenticating in Keycloak, I'm redirected to the Koha endpoint at http://localhost:8080/api/v1/public/oauth/login/Keycloak/opac which is a GET request. My request cookie has a CGISESSID value of 8435418b15fc0280af09f72a5f6c31cd. This is an anonymous session. My response cookie has a CGISESSID value of 1a11450a805d152b0dfcfcc91da3c341. This is an authenticated session. http://localhost:8080/api/v1/public/oauth/login/Keycloak/opac redirects as a GET request to opac-user.pl. Anti-CSRF shouldn't be involved here... -- I'm looking at Koha/REST/V1/OAuth/Client.pm and it looks OK to me. Personally, I would use a random value for a "state" parameter and save it to the session. Using a CSRF token in this case is problematic for a number of reasons I won't get into here. But the thing is... if you're getting wrong_csrf_token here it's because you've lost your session (well more specifically your userenv since master doesn't yet have the CSRF session fix Jonathan mentions above) between the time the "state" parameter was generated and the time the "state" parameter was checked. That means the test plan given in Comment 2 can't possibly work. Which takes me to Comment 10... there was something about navigating around Koha before posting the SSO login form. Now I have no idea why a person would do that, because it makes no sense at all. If you're clicking "Log in with Keycloak", then I'd just complete the login. But anyway... Recently I did notice that there is somewhere in Koha.. I think on the OPAC.. where the cookie isn't returned when it should be and that did cause me some grief. Let me try... -- You are receiving this mail because: You are watching all bug changes.