Ticket #1483986 (Bugs) Session expires
phil at cryer.us
Wed Sep 6 17:20:25 CEST 2006
On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli <roundcube at gmail.com> wrote:
> I hope I can give you some answers to your questions about session
> handling in RoundCube. Unfortunately, I cannot reproduce any session
> timeouts and because of that I'm unable to fix the bug...
I get this often - but I don't know how to trace it out. I've turned up logging to '4', but it didn't list anything around the time I got kicked out to the login screen. Luckily it had already saved a draft, so I only lost a little bit, but still, something is fishy. If anyone has an idea of how I can better trace things out (set it to '8'?) I'll do it to try to find the issue.
> Mr. B. Vrieling wrote:
>> Specifically, my suspicion is that the sess_gc() function is deleting
> sessions incorrectly (ie. prematurely).
>> 1. Why the custom session handling code? Was it for scaling with
> multiple servers? If I has only one server (a simple environment), what
> does storing the sessions in a database accomplish?
> I wanted to have all date stored in one place initially. Also there are
> (or have been) cache records that are related to a session and that
> should be deleted when the session ends or within the garbage collection
> routine. Having the sessions table replicated on several servers is just
> something theoretical that hasn't been used so far.
>> 2. If I disabled the garbage collection code (sess_gc) and allowed the
> stale sessions to collect rather than have them deleted, what would the
> impact of that be other than disk space in the database? I might manually
> hoof them all once a week.
> Should work. You can watch the table grow and remove old sessions
> manually or with a cron job.
>> 3. If the answer to the final part of #1 is "not a lot", what would
> happen if I did not install the custom session handlers and just let PHP's
> own code do it?
> Of course you can try that. Just remove the lines 85/86 in main.inc
> where the custom session handler is included.
>> I might be all wet and not understanding at all what the code is
> supposed to do. If so, please forgive me. However, I have users who really
> want to use RoundCube but the session expiry bug is killing them. I need a
> tactical solution until the real issue is addressed.
> Another place to debug this problem is in function
> rcmail_authenticate_session() which can be found in main.inc. If you set
> $CONFIG['session_lifetime'] to FALSE, the time check will be avoided but
> the validity of the session still will be checked in
> Some time ago, I removed the _auth hash in all URLs and added a second
> cookie that changes every 5 minutes. When the client sends it's
> keep-alive signal, a new cookie will be sent. To disable this security
> check, you simple let rcmail_authenticate_session() always return true.
> I hope these explanations will help you debug this. I'm really keen on
> what's the problem here...
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
http://fak3r.com - you don't have to kick it
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the Dev