On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli <[EMAIL PROTECTED]> 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. Thanks P > Mr. B. Vrieling wrote: >> Specifically, my suspicion is that the sess_gc() function is deleting > sessions incorrectly (ie. prematurely). >> >> QUESTIONS: >> >> 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.
