Session Expired

[timeuser]

My session is expiring during writing of emails. I'm typing along and all of a sudden it pops up the status thing at top and says "Session Expired" and kicks me out. It's pretty annoying as I lose whatever I was writiing. My session time in the main config is set to 300 minutes. Also my session seems to expire when I send a message. It sends successfully but imediately after sending it logs me out. Also, when I come back to the login page I get a session expired message, even though I haven't logged in yet. I do love RoundCube and have been using it for several months. This session expired stuff seems new since my install of 0.1 Beta 2.

Firefox 1.5.06, Mac OS X 10.4.7
My hosting is through Dreamhost.

[yllar]

set ip_check to FALSE and see if it happens again

[timeuser]

Yep, it is still expiring my sessions with ip_check set to FALSE.

[Heritz]

Actually, I think there is a problem with the code related to session auth. Sometimes and from some computers I dont get logged out, but from work and other places I got logged out. I made a modification to 2 files and now I have no more LOGOUT problems, sessions still expiring at the right time and the security is the same. Here is what you need to modify:

index.php
find... (line 177 to 17

if (!rcmail_authenticate_session() ||
  ($CONFIG['session_lifetime'] && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < mktime()))

replace for...

if (!rcmail_authenticate_session() ||
  ($_SESSION['auth_time'] + $CONFIG['session_lifetime']*60 < mktime()))

program/include/main.inc
find... and delete it (line 174 to 179)

 // renew auth cookie every 5 minutes (only for GET requests)
 if (!$valid || ($_SERVER['REQUEST_METHOD']!='POST' && $now-$_SESSION['auth_time'] > 300))
  {
  $_SESSION['auth_time'] = $now;
  setcookie('sessauth', rcmail_auth_hash(session_id(), $now));
  }

Try it and let me know. Regards!

[undefined]

is the bug you filed, http://trac.roundcube.net/trac.cgi/ticket/1483981 , a duplicate of http://trac.roundcube.net/trac.cgi/ticket/1483951 ? sounds like it.

i encountered this bug today (first time i've taken longer than a minute or two to compose an email) and it is annoying.

[desertadmin]

This session dumping seems to occur 1 minute after an autdraft occurs. has anyone else noticed this? Any one else have problems or did that change resolve it for you all?

-Sincerely,
DesertAdmin

[Heritz]

Originally Posted by undefined

is the bug you filed, http://trac.roundcube.net/trac.cgi/ticket/1483981 , a duplicate of http://trac.roundcube.net/trac.cgi/ticket/1483951 ? sounds like it.

i encountered this bug today (first time i've taken longer than a minute or two to compose an email) and it is annoying.

Hi, well my ticket is actually: http://trac.roundcube.net/trac.cgi/ticket/1483981

The other one its not mine. I reported the bug and I also gave a solution to fix it. Try the solution I posted a few days ago in this same thread. Hope it works for you.

[undefined]

Originally Posted by Heritz

Hi, well my ticket is actually: http://trac.roundcube.net/trac.cgi/ticket/1483981

The other one its not mine. I reported the bug and I also gave a solution to fix it. Try the solution I posted a few days ago in this same thread. Hope it works for you.

i know which ticket is your's because i clearly stated such in my original post (that you quoted).

i know you didn't author the other ticket i referenced because you are not listed as the author of that ticket. when i asked if it was a "duplicate", i was asking if the two tickets described the same underlying problem: unintentional session expirations while composing an email.

i know you gave a solution to fix it because i read your ticket and followed it to this thread and i've been analyzing your suggestion, but...

if after applying your "patch" auth_time is only ever set upon login (because auth_time is only ever set if it is not set, which should only occur at login), then your new code (ie "$_SESSION['auth_time'] + $CONFIG['session_lifetime']*60 < mktime()") will log a user out whether the user is actively using the session or not. with your code, if i set session_lifetime to 10 minutes, then after 10 minutes, whether i've been actively using the session or not, my session will expire and i will be logged out. i don't think that's the desired behavior.

from studying the original code, i believe the intention is that as long as i have roundcube "open" (ie displayed in my browser), the session should stay active. should i "close" roundcube, then the browser will stop sending keep-alives and the session will expire session_lifetime minutes later. (i believe the intention is to keep people from using my session some considerable time after i have stopped using it, like an hour later on a public internet terminal that does not purge cookies after every user).

so if my analysis is correct, then your code might fix the problem, but it definitely alters the session behavior of roundcube.

please correct me if i am wrong, as i have only had 30 minutes to study roundcube's source.

[undefined]

Originally Posted by desertadmin

This session dumping seems to occur 1 minute after an autdraft occurs. has anyone else noticed this? Any one else have problems or did that change resolve it for you all?

hmmm, one minutes after an autodraft. the keep-alives are sent at 1 minute intervals by the browser (and i presume it's hard coded as i haven't found a configuration option for that), so i wonder if the autodraft is somehow killing/deleting the session but it's not noticed until 1 minute later when the keep-alive is sent.

or maybe it's a race issue where session renewal (every 5 minutes) coincides with autodraft (also every 5 minutes?) and if an autodraft is executed then somehow the session renewal does not, so at the next keep alive it's then noticed that the user's session has expired. but that shouldn't be a problem because session expiration is configured for 10 minutes, not 5 minutes (at least for me; can't remember if i changed that from the default).

whatever the exact cause, i've also noticed that if the session expires during composing (sometimes it doesn't), it appears to be a minute after an autodraft.

[Heritz]

Hi,

Yes you are totally right, actually my idea is to simplify the code and fix the error problem we are all having. Besides, if I want the session to expire after 3 hours, it has to expire after 3 hours, not later, not before. Thats what I think, and thats what I actually want. In my opinion, 3 hours its fair enough to compose a main, or whatever you decide as "session expiring time".

I can retouch the code so the session wont expire till you close the window. But here is the thing that I cannot understand yet:

1. $SESS_CHANGED in index.php: where do they define this var?, I cant find this var being defined in main.inc. I don't know they value of this var.
2.

 // renew auth cookie every 5 minutes (only for GET requests)
 if (!$valid || ($_SERVER['REQUEST_METHOD']!='POST' && $now-$_SESSION['auth_time'] > 300))
  {
  $_SESSION['auth_time'] = $now;
  setcookie('sessauth', rcmail_auth_hash(session_id(), $now));
  }

$valid contains true or false based in the result of the function rcmail_auth_hash() compared to the value of $_COOKIE['sessauth']. If the values match (IP correct, session active, and other stuff), $valid=true, else, $valid=false. So, why do they reset the cookie if $valid=false? It should be something like:

 // renew auth cookie every 5 minutes (only for GET requests)
 if ($valid || ($_SERVER['REQUEST_METHOD']!='POST' && $now-$_SESSION['auth_time'] > 300))
  {
  $_SESSION['auth_time'] = $now;
  setcookie('sessauth', rcmail_auth_hash(session_id(), $now));
  }

So I reset the cookie if the validation of the hash is correct.

Please help me find the $SESS_CHANGED var so we can figure out the entire thing.