[Bug 38327] New: 403 errors when logging back into Koha.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Bug ID: 38327 Summary: 403 errors when logging back into Koha. Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: lucas@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org Firstly, I have been unable to recreate this issue myself, either in a production environment or in k-t-d. Many libraries are reporting 403 errors after signing back into Koha. The only remedy seems to be clearing the browser cache. This is happening to sessions in the staff client but also happening frequently in the SCO module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #1 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- To recreate: Generic: 1. Set timeout to something low for testing, I set mine to 10 seconds 2. Go to a page when you can do some kind of POST action 3. Wait for the timeout to happen 4. Do the post request thing, 5. You need to log back in, get a 403 error. My specific scenario: 1. Set timeout to something low for testing, I set mine to 10 seconds 2. Go to edit item page. 3. Wait for the timeout to happen 4. Try to delete an item, you are sent back to the home page. 5. When you log back there is a 403 error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|403 errors when logging |403 errors when logging |back into Koha. |back into Koha after | |timeout -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #2 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- My test plan recreates the problem in the staff interface but not in the SCO module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org --- Comment #3 from Phil Ringnalda <phil@chetcolibrary.org> --- You can see that those particular steps to reproduce are a duplicate of bug 37041 by editing the MARC framework you are testing against, and removing the plugin from any 952 subfield that has one. Then, you get a login form, log in, it didn't delete but if you try again within 10 seconds you can delete. Unfortunately, the real status of that bug is "In Argument." Not a fan of the way the system preference saving AJAX just silently eats a 403, so to reset timeout you have to log in on another page and get to resetting it before you time out again. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36586 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36514 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- When I heard about this one on Mattermost, I was thinking about bug 36586 In this case... it is probably related to bug 36514. Because if you're kicked out of Koha without a new anonymous session, you won't have a valid session, and thus won't be able to generate a valid CSRF token, so you'll get that 403 error. -- Looking at check_cookie_auth in C4::Auth, I can see the following: 1846 if ( !$lasttime || ( $lasttime < time() - $timeout ) ) { 1847 # time out 1848 $session->delete(); 1849 $session->flush; 1850 return ("expired", undef); I reckon that's the problem you're describing here. -- There's probably a bunch of places where we delete the session instead of removing the authenticated session and replacing with an anonymous session. But... needs more investigating. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bibliothek@th-wildau.de --- Comment #5 from Jan Kissig <bibliothek@th-wildau.de> --- I can easily recreate an 403 (running koha 24.05): - go to https://KOHA/cgi-bin/koha/mainpage.pl - when already logged in, click log out - then log in - 403 As my bookmark was to mainpage.pl I ran into this quite often. When starting from https://KOHA/ everything works as expected -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #6 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Jan Kissig from comment #5)
I can easily recreate an 403 (running koha 24.05):
- go to https://KOHA/cgi-bin/koha/mainpage.pl - when already logged in, click log out - then log in - 403
As my bookmark was to mainpage.pl I ran into this quite often. When starting from https://KOHA/ everything works as expected
I don't recreate using main. Do you? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #7 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Jan Kissig from comment #5)
I can easily recreate an 403 (running koha 24.05):
- go to https://KOHA/cgi-bin/koha/mainpage.pl - when already logged in, click log out - then log in - 403
As my bookmark was to mainpage.pl I ran into this quite often. When starting from https://KOHA/ everything works as expected
I have to correct my last comment: I had an AJAX call included via intranetuserjs on mainpage which fetched an internal report on $(document).ready(). When I disabled the fetch of the report the recreation of the behavior was not possible. So it seems connected to the AJAX-call after the DOM was built. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #7)
I have to correct my last comment: I had an AJAX call included via intranetuserjs on mainpage which fetched an internal report on $(document).ready().
When I disabled the fetch of the report the recreation of the behavior was not possible. So it seems connected to the AJAX-call after the DOM was built.
This has already been discussed somewhere... When Koha rendered mainpage.pl, it would've sent you CGISESSID cookie with an anonymous session ID and it rendered the page with a CSRF token linked to that session ID. When your AJAX call made a call, it probably didn't send that CGISESSID cookie. When your AJAX call gets a response, it probably includes a new CGISESSID cookie with a new anonymous session ID, which overwrites the original CGISESSID cookie. When you submit your login, you're using the new CGISESSID cookie and the CSRF token linked to the old CGISESSID cookie. So it'll never work. -- If you update your AJAX call to send with the CGISESSID cookie, you should be fine. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- Btw which AJAX call were you making? We might want to fix that endpoint to not send back a cookie. I think that there might be a bug report where we talked about that topic specifically... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #10 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #9)
Btw which AJAX call were you making? We might want to fix that endpoint to not send back a cookie.
I think that there might be a bug report where we talked about that topic specifically...
on an private window with cookies deleted I opened(In reply to David Cook from comment #8)
(In reply to Jan Kissig from comment #7)
I have to correct my last comment: I had an AJAX call included via intranetuserjs on mainpage which fetched an internal report on $(document).ready().
When I disabled the fetch of the report the recreation of the behavior was not possible. So it seems connected to the AJAX-call after the DOM was built.
This has already been discussed somewhere...
When Koha rendered mainpage.pl, it would've sent you CGISESSID cookie with an anonymous session ID and it rendered the page with a CSRF token linked to that session ID.
When your AJAX call made a call, it probably didn't send that CGISESSID cookie.
When your AJAX call gets a response, it probably includes a new CGISESSID cookie with a new anonymous session ID, which overwrites the original CGISESSID cookie.
When you submit your login, you're using the new CGISESSID cookie and the CSRF token linked to the old CGISESSID cookie.
So it'll never work.
--
If you update your AJAX call to send with the CGISESSID cookie, you should be fine.
I took a look at the network requests: On a pivate window I opened my bookmark to /cgi-bin/koha/mainpage.pl it returned a cookie with CGISESSID 67cd... the fetch on document.ready to /cgi-bin/koha/svc/report?id=9 used this cookie (67cd...) in the request but got a new CGISESSID 0bc5... Now I enter the login and submit the page which uses 0bc5... I understand why CSRF-check is failing here as the login-form is linked to the first session 67cd The problem is that the fetch, although it used the given session id, got a new in response which replaced the original. I solved it by only sending the fetch if the login was successful -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #11 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #9)
Btw which AJAX call were you making? We might want to fix that endpoint to not send back a cookie.
I think that there might be a bug report where we talked about that topic specifically...
It was an AJAX to an internal report: https://mykoha/cgi-bin/koha/svc/report?id=9 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #10)
I took a look at the network requests: On a pivate window I opened my bookmark to /cgi-bin/koha/mainpage.pl it returned a cookie with CGISESSID 67cd... the fetch on document.ready to /cgi-bin/koha/svc/report?id=9 used this cookie (67cd...) in the request but got a new CGISESSID 0bc5...
Now I enter the login and submit the page which uses 0bc5...
I understand why CSRF-check is failing here as the login-form is linked to the first session 67cd
The problem is that the fetch, although it used the given session id, got a new in response which replaced the original.
I solved it by only sending the fetch if the login was successful
Alternatively, you can send the cookie provided by /cgi-bin/koha/mainpage.pl to the endpoint /cgi-bin/koha/svc/report?id=9 I don't know how your Javascript is written, but do some googling around for things like: const xhr = new XMLHttpRequest(); xhr.withCredentials = true; With fetch, set the "credentials" option to "same-origin" or "include" (depending on your situation). With $.ajax, set xhrFields with "withCredentials: true". I think you probably get my point here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #11)
On a pivate window I opened my bookmark to /cgi-bin/koha/mainpage.pl it returned a cookie with CGISESSID 67cd... the fetch on document.ready to /cgi-bin/koha/svc/report?id=9 used this cookie (67cd...) in the request but got a new CGISESSID 0bc5...
My apologies, after re-reading your comment, I see you said that your AJAX request *did* send the original cookie to /cgi-bin/koha/svc/report?id=9 but that it got a different one back. So your login is for the staff interface... are you calling the report endpoint for the staff interface or the OPAC? I note that /cgi-bin/koha/svc/report doesn't return a cookie on a succesful request, but I do see that the staff interface version does do a get_template_and_user() check on /cgi-bin/koha/svc/report which... is not the right thing to do at all for that endpoint, as I suspect it is failing the auth check and serving you back with a HTML response instead of a JSON response. Ugh. -- (In reply to Jan Kissig from comment #10)
I solved it by only sending the fetch if the login was successful
Check out bug 37056. It looks like it's fixed in newer versions. Anyway, we've distracted away from Lucas's other bug here... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37056 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aleisha@catalyst.net.nz --- Comment #14 from Aleisha Amohia <aleisha@catalyst.net.nz> --- I THINK we've seen this happen on the OPAC as well. 1. Was logged into the OPAC 2. Left ... assuming Koha timed out 3. Came back to the OPAC and tried to log in again 4. Successful login, but shown a 403 error with "Form submission: wrong_csrf_token" . or sometimes, not even a successful login. Is this the same error? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (In reply to Lucas Gass (lukeg) from comment #0)
Firstly, I have been unable to recreate this issue myself, either in a production environment or in k-t-d.
Many libraries are reporting 403 errors after signing back into Koha. The only remedy seems to be clearing the browser cache.
This is happening to sessions in the staff client but also happening frequently in the SCO module.
Btw, bug 36586 should explain the SCO issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to Aleisha Amohia from comment #14)
I THINK we've seen this happen on the OPAC as well.
1. Was logged into the OPAC 2. Left ... assuming Koha timed out 3. Came back to the OPAC and tried to log in again 4. Successful login, but shown a 403 error with "Form submission: wrong_csrf_token" . or sometimes, not even a successful login.
Is this the same error?
Sounds like it. I haven't gotten any complaints like this yet, but I should take a look sometime... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Michael Grgurev <mike.grgurev@mainlib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mike.grgurev@mainlib.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Michael Kuhn <mik@adminkuhn.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mik@adminkuhn.ch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Matthias Meusburger <matthias.meusburger@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37060 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 [Bug 37060] KOCT cannot send circulation data due to missing CSRF token -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- (In reply to Lucas Gass (lukeg) from comment #1)
To recreate:
Generic: 1. Set timeout to something low for testing, I set mine to 10 seconds 2. Go to a page when you can do some kind of POST action 3. Wait for the timeout to happen 4. Do the post request thing, 5. You need to log back in, get a 403 error.
So you don't even need a POST. You can just do a GET. Anyway, I set "timeout" to "10", logged in, waited 10 seconds, then went to another page. My first session had a cookie with a session ID of b49e79b4392bb8eff50400904a7f7481 which appears to have been removed from the database... On the login page with "Error: Session timed out" I see a cookie with a session ID of 637b52999bc5266c383faf809a8761d8. However, I don't see a session with that ID in the database. I waited a while to try logging in again... and now I'm able to log in fine, which is actually surprising. After the successful login I have an ID of 38f2a4db6f1e9806d5b731b6f098298d which does appear in the database... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #17)
On the login page with "Error: Session timed out" I see a cookie with a session ID of 637b52999bc5266c383faf809a8761d8. However, I don't see a session with that ID in the database.
I waited a while to try logging in again... and now I'm able to log in fine, which is actually surprising. After the successful login I have an ID of 38f2a4db6f1e9806d5b731b6f098298d which does appear in the database...
I guess we're just checking the session ID against the CSRF token rather than validating the session ID against the database, which I guess is all right. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- So yeah I can't reproduce this in main. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42494 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org