https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33259 --- Comment #55 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #54)
Interestingly, when Keycloak POSTs a 302 to Koha it doesn't work, but there is a scenario with Keycloak where a Strict cookie is still sent after a redirect.
If I log into Keycloak first, and then I go to Koha and click "Log in with Keycloak", I'm redirected from Koha to Keycloak and redirected from Keycloak to Koha. In this situation where it's two GET 302s in a row, the Strict cookie is still sent, and I'm logged into Koha using Keycloak.
I'm not describing this right. With Strict, it's failing because Keycloak is doing a GET to Koha and that's not allowed. With Lax, it's succeeding because it's allowed for Keycloak to do a GET to Koha. And I think in the scenario where it goes Koha -> Keycloak -> Koha will all 302s, I think the browser is considering that to be user-initiated from the Koha side, and that's why it's allowing it to send the cookie. Because we have a POST to Keycloak with the login, that's why it won't let us login with Keycloak when Strict is in use. I think that brings me back to anonymous CGISESSID cookies needing to be Lax, even if an authenticated CGISESSID cookie is Strict. -- You are receiving this mail because: You are watching all bug changes.