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.
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.