| Summary: | 403 errors when logging back into Koha after timeout | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Lucas Gass (lukeg) <lucas> |
| Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | blawlor, dcook, jonathan.druart, phil |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36586 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36514 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Lucas Gass (lukeg)
2024-11-01 16:44:09 UTC
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. My test plan recreates the problem in the staff interface but not in the SCO module. 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. 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. |