Bug 56052 - ap_session_load called multiple times for expired session creates new session each time
Summary: ap_session_load called multiple times for expired session creates new session...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_session (show other bugs)
Version: 2.4.7
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2014-01-22 18:50 UTC by Erik Pearson
Modified: 2020-03-01 22:42 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Erik Pearson 2014-01-22 18:50:09 UTC
The mechanism for calling ap_session_load causes problems when a session has expired. This is because the core ap_session_load function will create a new session if the current one has expired, yet the session load hook function will be blissfully unaware.

The current session is loaded from the current ap session load hook (e.g. mod_session_cookie, mod_session_dbd). The session load hook function, however, takes responsibility for looking for and storing the session within the notes table. (I'm just getting up to speed with the mechanics, so bear with me if I use slightly the wrong words.)

Consider this code flow:

in client code (e.g. mod_auth_form)
ap_session_load called
ap_session_load calls current load hook
load hook gets the session from the notes if it is there, or from the source (cookie, dbd)
load hook then stores it in the notes and returns the session object
back in ap_session_load, the returned session is found to be expired, so a new one is created
the new one is returned to the client code

the client code will manipulate the session, e.g. adding authentication information in the case of mod_auth_form

later on in the request, the session modules output filter is run
the session is loaded again, then saved. 
Unfortunately, the loading will repeat the process above, which will result in producing another new session, since the original one has expired. 
The new session will be saved, resulting in a session without the client's modifications. 

e.g. in the case of mod_auth_form, the session will no longer be authenticated, and the resulting cookie, in the case of mod_session_cookie, will not have the authentication information that should be there after a successful login.

I think the root of the problem is that the note retrieval and saving code is conducted within the session load hook. If were done in mod_session_load, subsequent calls to mod_session_load would get the correct session (that is, the session that resulted from the first time it was called.)

As well as solving this problem, it would be a better design. There is nothing special in the load hooks with regard to loading and saving the session in the notes, other than using the load hook name as the key. Unless there is a good reason for the session to be available in the notes via the load hook key, I don't see why that code can't be moved in to ap_session_load.

If that were not the case, there would need to be an extension to the load hook api so that ap_session_load could have the load hook deal with the newly created session (adding some default values, storing it in the notes  under its own key, etc.)
Comment 1 Eric Covener 2020-03-01 22:42:20 UTC
http://svn.apache.org/viewvc?rev=1874673&view=rev works around this without disrupting either side too much.