Summary | Memcache Session handler, shouldn't unlock if no data in memcache |
Queue | Horde Framework Packages |
Queue Version | HEAD |
Type | Bug |
State | No Feedback |
Priority | 1. Low |
Owners | slusarz (at) horde (dot) org |
Requester | urkle (at) outoforder (dot) cc |
Created | 11/20/2008 (6048 days ago) |
Due | |
Updated | 12/14/2008 (6024 days ago) |
Assigned | 12/02/2008 (6036 days ago) |
Resolved | 12/14/2008 (6024 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Feedback
http://marc.info/?l=horde&m=122660520206201&w=2
Assigned to Michael Slusarz
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Memcache Session handler, shouldn't unlock if no data in memcache
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
(and the FW 3 Branch), it seems that there is a locking issue that can
occur on new sessions.
In the code you
1) create a lock
2) try and read the data from memcache. (in case of a new session this
will be nothing)
3) if there is no data then you release the lock
.... Later on page close
1) write the data (creating a new session)
2) release lock if set.
Now, the issue is if two requests happen to occur around the same time
when there is no session data (ie.. expired) then there is a high
probability that they will overwrite each other.
Example
Req 1> New Request
Req 1> Fetch Session (no data, expired, release lock)
Req 2> New Request
Req 2> Fetch Session (No data, expired, release lock)
Req 2> Processing
Req 2> Store Session
Req 2> End Request
Req 1> Store Session
Req 1> End Request
Because there is no lock, Req 1 overwrites Req 2s data (and Req 2 is
allowed to actually run even though it should have waited for Req 1).
The worse case is this, (ie login scenario)
R 1> New Request
R 1> Fetch Session (no data, expired, release lock)
R 1> Login attempt
R 2> Nww Request
R 2> Fetch Session (no data, expired, release lock)
R 1> Process Login
R 2> Do something else
R 1> Store Session
R 1> End Request
R 2> Store Session (Overwriting Requests 1's login session)
R 2> End Request
This results in the users session being overwritten by another request
that user pushed through and thus, they are not logged in.
The solution would be to *NOT* release the lock if there is no
session, because we ARE going to be writing at the end of the request.