Bug 58171

Summary: ap_session_save saves the wrong session after a decode error
Product: Apache httpd-2 Reporter: Paul Spangler <paul.spangler>
Component: mod_sessionAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal Keywords: FixedInTrunk
Priority: P2    
Version: 2.5-HEAD   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description Paul Spangler 2015-07-22 14:30:55 UTC 
This issue is very similar to 56052 which deals with expired sessions. If a session fails to decode (such as a changed key for mod_session_crypto), mod_session will automatically create a new one to return from ap_load_session.

The problem is the session sub-module, such as mod_session_cookie, has already cached the original session in the request notes. The next time ap_load_session is called (such as during ap_save_session), the old session struct is retrieved, which still fails to decode, and another new session is created. Any data written to the first new session is now gone, and the empty session gets saved.

It is likely the fix for this will be the same as for 56052, but I didn't want this one to be missed when the expiry one is fixed.

Steps to Reproduce:

1. Configure the server using mod_auth_form, mod_session, mod_session_cookie, and mod_session_crypto.
2. Start the server.
3. Log in via mod_auth_form. This creates a session saved in a cookie.
4. Change the SessionCryptoPassphrase and reload the server config.
5. Try to log in again. The existing session cookie will fail to decode and it fails to log in.
Comment 1 Eric Covener 2020-03-01 22:44:22 UTC 
Presumably due to some other changes, I couldn't get the same symptom until a change to mod_session_crypto. but after that http://svn.apache.org/viewvc?rev=1874673&view=rev alleviates the looping without new APIs or too much disruption.