Ticket #1483986 (Bugs) Session expires

phil 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
> rcmail_authenticate_session()
> 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...
> Regards,
> Thomas
> --
> 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 mailing list