I just added this ticket. Am I the only one with this problem or do I have "expired buddies". :-)
I can't find error messages anywhere, so I'm kind of lost. :-(
Any ideas on how to debug this?
P.D.: I'm "At revision 327".
--
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
On Wed, 30 Aug 2006 11:45:12 -0300, Martin Marques martin@bugs.unl.edu.ar wrote:
I just added this ticket. Am I the only one with this problem or do I have "expired buddies". :-)
You know, I was seeing this earlier in the week, and was going to look into it to see if it was a known bug. Just since you mentioned it I checked my config, and since I upgraded to a newer file I must have missed the option, I had this set to only 10 mins:
// session lifetime in minutes $rcmail_config['session_lifetime'] = 10;
Do you have that set to something higher? I've set it to 100 on my -svn version and will see if I get any more timeouts today.
Thanks
P
I can't find error messages anywhere, so I'm kind of lost. :-(
Any ideas on how to debug this?
P.D.: I'm "At revision 327".
--
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
-- http://fak3r.com - you don't have to kick it
On Wed, 30 Aug 2006 9:51:19 -0500, phil phil@cryer.us wrote:
On Wed, 30 Aug 2006 11:45:12 -0300, Martin Marques martin@bugs.unl.edu.ar wrote:
I just added this ticket. Am I the only one with this problem or do I have "expired buddies". :-)
You know, I was seeing this earlier in the week, and was going to look into it to see if it was a known bug. Just since you mentioned it I checked my config, and since I upgraded to a newer file I must have missed the option, I had this set to only 10 mins:
// session lifetime in minutes $rcmail_config['session_lifetime'] = 10;
Do you have that set to something higher? I've set it to 100 on my -svn version and will see if I get any more timeouts today.
Changed it with no luck, so that's not the problem. :-(
--
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
Martin Marques wrote:
On Wed, 30 Aug 2006 9:51:19 -0500, phil phil@cryer.us wrote:
On Wed, 30 Aug 2006 11:45:12 -0300, Martin Marques martin@bugs.unl.edu.ar wrote:
I just added this ticket. Am I the only one with this problem or do I have "expired buddies". :-)
You know, I was seeing this earlier in the week, and was going to look into it to see if it was a known bug. Just since you mentioned it I checked my config, and since I upgraded to a newer file I must have missed the option, I had this set to only 10 mins:
// session lifetime in minutes $rcmail_config['session_lifetime'] = 10;
Do you have that set to something higher? I've set it to 100 on my -svn version and will see if I get any more timeouts today.
Changed it with no luck, so that's not the problem. :-(
I had a similar problem after updating one of my roundcube installs, but clearing my cache out fixed it. It kept bumping me out while composing a long e-mail that I kept having to walk away from. It would save the draft and then a short while later (never did time it), it expired my session. I cleaned out my cache, restarted the browser (Firefox) and it's been fine ever since.
Even if clearing the cache doesn't fix it, sometimes holding shift while clicking the reload button will force a non-cached reload. I've had to do that when working with CSS and JS in the past.
Jim
On Wed, 30 Aug 2006, Jim Pingle wrote:
Martin Marques wrote:
On Wed, 30 Aug 2006 9:51:19 -0500, phil phil@cryer.us wrote:
Changed it with no luck, so that's not the problem. :-(
I had a similar problem after updating one of my roundcube installs, but clearing my cache out fixed it. It kept bumping me out while composing a long e-mail that I kept having to walk away from. It would save the draft and then a short while later (never did time it), it expired my session. I cleaned out my cache, restarted the browser (Firefox) and it's been fine ever since.
My problem is not when composing, but when reading the message list.
BTW, setting ip_check to false didn't fix anything.
Another thing. This happens when I execute lots of actions, like hitting the delete botton lots of times.
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
Hello,
On Thu, 31 Aug 2006 11:48:36 -0300 (ART), Martin Marques martin@bugs.unl.edu.ar wrote:
My problem is not when composing, but when reading the message list.
BTW, setting ip_check to false didn't fix anything.
Another thing. This happens when I execute lots of actions, like hitting the delete botton lots of times.
I can confirm that after setting my session lifetime to 30 and setting IP_CHECK to FALSE, the problem has not been fixed. My sessions continue to expire at odd times, most annoyingly during message creation and sending. (I don't have caching enabled, and this is on an uptodate FC5 server running 0.1beta2.)
Is there an easy way to just turn session expiring OFF entirely? Hoofing that functionality is better than the current situation.
Thanks.
..Bruce
Further to my previous email:
My suspicion is that the bug is in RoundCube's custom session handling code. As I poke in program/include/session.inc I note that Roundcube installs custom PHP session handlers here:
// set custom functions for PHP session management session_set_save_handler('sess_open', 'sess_close', 'sess_read', 'sess_write','sess_destroy', 'sess_gc');
Specifically, my suspicion is that the sess_gc() function is deleting sessions incorrectly (ie. prematurely).
QUESTIONS:
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?
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.
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?
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.
Thanks!
..Bruce
On Mon, 4 Sep 2006 10:05:35 -0400, "Mr. B. Vrieling" bvrieling@tdchristian.ca wrote:
Hello,
On Thu, 31 Aug 2006 11:48:36 -0300 (ART), Martin Marques martin@bugs.unl.edu.ar wrote:
My problem is not when composing, but when reading the message list.
BTW, setting ip_check to false didn't fix anything.
Another thing. This happens when I execute lots of actions, like hitting the delete botton lots of times.
I can confirm that after setting my session lifetime to 30 and setting IP_CHECK to FALSE, the problem has not been fixed. My sessions continue to expire at odd times, most annoyingly during message creation and sending. (I don't have caching enabled, and this is on an uptodate FC5 server running 0.1beta2.)
Is there an easy way to just turn session expiring OFF entirely? Hoofing that functionality is better than the current situation.
Thanks.
..Bruce
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...
Mr. B. Vrieling wrote:
Specifically, my suspicion is that the sess_gc() function is deleting sessions incorrectly (ie. prematurely).
QUESTIONS:
- 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.
- 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.
- 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
Thomas,
Thanks a lot for your input.
Further question:
On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli roundcube@gmail.com wrote:
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()
Is that a new change? In beta2, session_lifetime is a value, not a boolean. If I were to set it to FALSE, some of the math would be odd.... like here:
ini_set('session.gc_maxlifetime', ($CONFIG['session_lifetime']+2)*60);
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...
I'll poke, and report back what I find.
Thanks for the help!
..Bruce
On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli roundcube@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.
Thanks
P
Mr. B. Vrieling wrote:
Specifically, my suspicion is that the sess_gc() function is deleting
sessions incorrectly (ie. prematurely).
QUESTIONS:
- 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.
- 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.
- 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
Hi all,
While I won't claim that I have fixed *the* session expiry problem, if the lack of recent complaints from my users is any indication, I have fixed *my* session expiry problem.
Following up on a tip from Thomas, I disabled the rcmail_authenticate_session() function in /program/include/main.inc. As Thomas explained, this piece of code does a double check on a cookie dropped in the client as a security check. To disable it, I changed the "return $valid;" at the end of this function to "return TRUE;" and the complaints I had been receiving died just like that.
DISCLAIMER: While I don't recall changing anything else of significance around the same time, I might have. I have been poking around a little.... So while I *think* the above fixed the problem for me, someone else had better verify it.
..Bruce
On Wed, 6 Sep 2006 11:16:24 -0400, "Mr. B. Vrieling" bvrieling@tdchristian.ca wrote:
Thomas,
Thanks a lot for your input.
Further question:
On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli roundcube@gmail.com wrote:
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()
Is that a new change? In beta2, session_lifetime is a value, not a boolean. If I were to set it to FALSE, some of the math would be odd.... like here:
ini_set('session.gc_maxlifetime', ($CONFIG['session_lifetime']+2)*60);
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...
I'll poke, and report back what I find.
Thanks for the help!
..Bruce
Mr. B. Vrieling wrote:
Hi all,
While I won't claim that I have fixed *the* session expiry problem, if the lack of recent complaints from my users is any indication, I have fixed *my* session expiry problem.
Following up on a tip from Thomas, I disabled the rcmail_authenticate_session() function in /program/include/main.inc. As Thomas explained, this piece of code does a double check on a cookie dropped in the client as a security check. To disable it, I changed the "return $valid;" at the end of this function to "return TRUE;" and the complaints I had been receiving died just like that.
At least we're digging in the right direction... I added some fall back checking to that methods. Please get the latest trunk and try it out.
Regards, Thomas
All I did was put the return true (no other changes made to the code), and it seems to work ok. So the problem is in someplace of the rcmail_authenticate_session().
On Thu, 7 Sep 2006, Mr. B. Vrieling wrote:
Hi all,
While I won't claim that I have fixed *the* session expiry problem, if the lack of recent complaints from my users is any indication, I have fixed *my* session expiry problem.
Following up on a tip from Thomas, I disabled the rcmail_authenticate_session() function in /program/include/main.inc. As Thomas explained, this piece of code does a double check on a cookie dropped in the client as a security check. To disable it, I changed the "return $valid;" at the end of this function to "return TRUE;" and the complaints I had been receiving died just like that.
DISCLAIMER: While I don't recall changing anything else of significance around the same time, I might have. I have been poking around a little.... So while I *think* the above fixed the problem for me, someone else had better verify it.
..Bruce
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
-
Jim Pingle -
Martin Marques -
Mr. B. Vrieling -
phil -
Thomas Bruederli