Jonathan Angliss wrote:
Hello John Madden, On Thursday, April 28, 2005, you wrote:
- User 1 logs in to webserver 1, gets session id abc123
- User 2 logs in to webserver 2, gets session id abc123 and trashes current contents of abc123 session file
If using NFS as the session store, you don't even have to get this specific -- one user using "his" session from two servers simultaneously will eventually see problems.
I'm wondering if PHP is doing the trashing for "security" reasons. I'll have to take a peek of the code, but from a guess, it'd sound like the web server sees the user requesting the session file, but it has an internal store of "valid" sessions, and the session file there doesn't match one in the internal store of which sessions are valid... as such, it'd probably just "zap" it.
Huh, well that would suck. It is not uncommon for PHP to be used in multiple-server environments, so I would not be surprised if either you are wrong, or PHP has a way to change this. A quick browse of the session page at php.net and Google turned up nothing much about how the internals work, but I am wondering if a crude application-side hack might be possible to further reduce the chances of this happening. This could be a starting point (although I have not looked at the code):
http://phpclasses.promoxy.com/browse/package/1840.html
But still, that would be code run past the failure point, so might not work at all... um, unless it could be written to access our own hacked up file system-based lock file over NFS or whatever. Yuck.
Oh, here's another example that just came to mind. It didn't happen under SQM 1.2.x, but under 1.4.x with NFS-shared userprefs files, I observed the entire file being lost and started from scratch. I was able to cause this to happen a couple dozen times without finding out exactly what was causing it, but it seems consistent with what we've been discussing. That prompted a quick switch to SQL-based prefs.
Wonder if this is because of how we are doing the preference files now. If I remember correctly, in the 1.2.x series, we just overwrite the preference file, in the 1.4.x series, we create a temporary file, then zap the real one, and rename the temporary file. I wonder if the unlink/rename code is being caught by file locking somehow.
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: [email protected] List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
