-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, November 1, 2005 13:56, john crawford wrote: >>> As a quick ugly patch, if I just delete the sess_deleted file from >>> cron, the effective user would have to log in again. Wouldn't they get >>> a valid session token the second >> time around? >> I am not 100% sure about this ..... but what I can see in the logs is >> that the same users have the same problem again and again so they don't >> get a valid session token the second time. > Okay, well I did put into effect the modifications that Jonathan > recommended and so I believe I'm regenerating cookies if the "deleted" > cookie is stored by the client. Excellent... I'd be happy to know how that runs for you. The only issue that has been brought to my/our attention was by Tomas on systems that have different locales set, the float values can end up appearing very differently, and will probably have quite a large affect on it. > Rafael, I'm wondering why you combined a test for a 32 char string with > your "deleted" test. > From Aug 26: > >> We patched our code so it does not use a SID with a value like >> 'deleted' or not a 32 long char string and the problem is gone. > Why the 32 char string test? I'm not sure why you included that. I believe md5 returns a 32 character string, which is what PHP uses to generate a "safe" cookie/session id (see the end of the code I gave you). > By the way, one of the user's who was involved in the pref mixup incident > (user "a") has checked and did find the system date of the client > was off by much more than 1 year and one day. So maybe that explains the > cookie expiration not taking effect. (Though I would hope that timeout > values would have some other reference than client-set-time). Cookie expiration is browser side only as far as I can tell. The server doesn't record what cookies it handed out, or their duration. Assuming we sent a cookie with a date of say 30 days ago, the 1 year and 1 hour clock offset would mean the cookie is set to expire in 335 days, and not 30 days ago. Looking at the code briefly, the actual expiry time is set to "time() - - 5" meaning 5 seconds ago. That is actually rather... er... "crappy" as that is only 5 seconds ago, and it could very easily be a case of the users' computer being off by several minutes. We should probably change that to something a little more "real world" safe, like 30 days in the past. Though that won't help in your case, it should certainly help aleviate the possible issues. Session timeouts are based on the last access time of the session file assuming your file system supports access time (see http://www.php.net/session in particular session.gc_maxlifetime). - -- Jonathan Angliss <[EMAIL PROTECTED]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkNn7Z0ACgkQK4PoFPj9H3OpdwCdHYxygo76EZjyCxdzr1A1Y5nP QF8AoMW2eFsl/DFq+rrKzquzUtIHm/BS =oXdH -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- squirrelmail-users mailing list Posting Guidelines: http://www.squirrelmail.org/wiki/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)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
