Hi all,
I'm trying to set up a new installation of Roundcube-RC1.1. I have set everything up and created the database with the supplied schema. When I try to log in, I get the error "Your session is invalid or expired." Note that supplying an incorrect login/pass gives the expected "login failed" message.
I tried searching for this error on the web and found one other instance of this problem, but the cause of that problem was on IIS (and was fixed anyway), so I don't think it is related (http://trac.roundcube.net/trac.cgi/ticket/1483806). I get the same behavior in both Firefox and Safari.
I have $rcmail_config['debug_level'] = 4; but are no messages displayed besides the one mentioned above, and nothing is written to the logs directory.
I have had another installation of Roundcube running on the same server in another directory (and with a different DB) successfully - from an older CVS dump in 2006.
We are running FreeBSD, MySQL 4.1.15 and lighttpd 1.4.8
Has anyone else run into this problem? Any clues as to it's cause?
Thanks in advance. Benjamin
I am having the same issue. This is a brand new install of 0.1-rc1-1 and I keep getting "Your session is invalid or expired" when I try to login. It is successfully creating the new user account after authentication via imap-ssl and it is also adding a session to the database. However, I still can not login.
David
David Cramblett wrote:
Hi all,
I'm trying to set up a new installation of Roundcube-RC1.1. I have set everything up and created the database with the supplied schema. When I try to log in, I get the error "Your session is invalid or expired." Note that supplying an incorrect login/pass gives the expected "login failed" message.
I tried searching for this error on the web and found one other instance of this problem, but the cause of that problem was on IIS (and was fixed anyway), so I don't think it is related (http://trac.roundcube.net/trac.cgi/ticket/1483806). I get the same behavior in both Firefox and Safari.
I have $rcmail_config['debug_level'] = 4; but are no messages displayed besides the one mentioned above, and nothing is written to the logs directory.
I have had another installation of Roundcube running on the same server in another directory (and with a different DB) successfully - from an older CVS dump in 2006.
We are running FreeBSD, MySQL 4.1.15 and lighttpd 1.4.8
Has anyone else run into this problem? Any clues as to it's cause?
Thanks in advance. Benjamin
I am having the same issue. This is a brand new install of 0.1-rc1-1 and I keep getting "Your session is invalid or expired" when I try to login. It is successfully creating the new user account after authentication via imap-ssl and it is also adding a session to the database. However, I still can not login.
David
I traced through the code (hooray open source) and was able to skirt the issue by disabling session expiration. (comment out $rcmail_config['session_lifetime'] or set it to '')
My research showed that the rcmail_authenticate_session() function was being called twice per request. On the first attempt to log in (cleared sessions table), the function returns true the first time and then false the second time. Subsequent requests return false both times. It was getting set to false on this line: if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < time()) $valid = false;
hence the workaround by setting changing the session_lifetime value.
Benjamin
Benjamin Bradley wrote:
I traced through the code (hooray open source) and was able to skirt the issue by disabling session expiration. (comment out $rcmail_config['session_lifetime'] or set it to '')
My research showed that the rcmail_authenticate_session() function was being called twice per request. On the first attempt to log in (cleared sessions table), the function returns true the first time and then false the second time. Subsequent requests return false both times. It was getting set to false on this line: if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < time()) $valid = false;
I cannot confirm that rcmail_authenticate_session() is called twice per request. It is only called by index.php and this is only run once per request. Of course index.php is also run on ajax requests which are sent periodically (every 60 seconds) to keep up the session by updating the changed date in the sessions table.
Unfortunately I cannot reproduce these timeouts. Please add the following code at the end of rcmail_authenticate_session(), right before return $valid; and send me the logged data which will be written to logs/authenticate
write_log('authenticate', $_SERVER['REQUEST_URI'] . "; changed = " . date('r', $SESS_CHANGED) . "; valid = $valid");
With this info I might be able to find the "real" reason for the session timeout problem.
Regards, Thomas
On 6/27/07, Thomas Bruederli roundcube@gmail.com wrote:
Benjamin Bradley wrote:
I traced through the code (hooray open source) and was able to skirt the issue by disabling session expiration. (comment out $rcmail_config['session_lifetime'] or set it to '')
My research showed that the rcmail_authenticate_session() function was being called twice per request. On the first attempt to log in (cleared sessions table), the function returns true the first time and then false the second time. Subsequent requests return false both times. It was getting set to false on this line: if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < time()) $valid = false;
I cannot confirm that rcmail_authenticate_session() is called twice per request. It is only called by index.php and this is only run once per request. Of course index.php is also run on ajax requests which are sent periodically (every 60 seconds) to keep up the session by updating the changed date in the sessions table.
Unfortunately I cannot reproduce these timeouts. Please add the following code at the end of rcmail_authenticate_session(), right before return $valid; and send me the logged data which will be written to logs/authenticate
write_log('authenticate', $_SERVER['REQUEST_URI'] . "; changed = " . date('r', $SESS_CHANGED) . "; valid = $valid");
With this info I might be able to find the "real" reason for the session timeout problem.
Regards, Thomas
Hello Thomas,
This is not connected with expired sessions, but a related issue.
Now that you have mentioned the matter, I am taking this up once again. There was a post in the forum on how to change the ajax request frequency. The 60 seconds is too high for some servers which has more number of users.
How do I change this?
Regards
kmn
kmnair wrote:
Hello Thomas,
This is not connected with expired sessions, but a related issue.
Now that you have mentioned the matter, I am taking this up once again. There was a post in the forum on how to change the ajax request frequency. The 60 seconds is too high for some servers which has more number of users.
How do I change this?
Open program/js/app.js and change the value for 'this.env.keep_alive' at line 49.
~Thomas
On 6/27/07, Thomas Bruederli roundcube@gmail.com wrote:
kmnair wrote:
Hello Thomas,
This is not connected with expired sessions, but a related issue.
Now that you have mentioned the matter, I am taking this up once again. There was a post in the forum on how to change the ajax request frequency. The 60 seconds is too high for some servers which has more number of users.
How do I change this?
Open program/js/app.js and change the value for 'this.env.keep_alive' at line 49.
~Thomas
Thank you Thomas.
That was lightning fast.
Regards
kmn
Thomas Bruederli wrote:
Benjamin Bradley wrote:
I traced through the code (hooray open source) and was able to skirt the issue by disabling session expiration. (comment out $rcmail_config['session_lifetime'] or set it to '')
My research showed that the rcmail_authenticate_session() function was being called twice per request. On the first attempt to log in (cleared sessions table), the function returns true the first time and then false the second time. Subsequent requests return false both times. It was getting set to false on this line: if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < time()) $valid = false;
I cannot confirm that rcmail_authenticate_session() is called twice per request. It is only called by index.php and this is only run once per request. Of course index.php is also run on ajax requests which are sent periodically (every 60 seconds) to keep up the session by updating the changed date in the sessions table.
Unfortunately I cannot reproduce these timeouts. Please add the following code at the end of rcmail_authenticate_session(), right before return $valid; and send me the logged data which will be written to logs/authenticate
write_log('authenticate', $_SERVER['REQUEST_URI'] . "; changed = " . date('r', $SESS_CHANGED) . "; valid = $valid");
With this info I might be able to find the "real" reason for the session timeout problem.
Regards, Thomas
Thomas, Thank you for your attention. Here is output in logs/authenticate from several different setups:
logging in with session_lifetime disabled: [28-Jun-2007 23:44:26 -0400]: /; changed = Thu, 28 Jun 2007 22:54:09 -0400; valid = 1 [28-Jun-2007 23:44:26 -0400]: /?_task=mail; changed = Thu, 28 Jun 2007 22:54:12 -0400; valid = 1 [28-Jun-2007 23:44:31 -0400]: /?_task=mail&_action=getunread&_remote=1; changed = Thu, 28 Jun 2007 22:54:15 -0400; valid = 1
logging in with session_lifetime enabled: [28-Jun-2007 23:45:39 -0400]: /; changed = Thu, 28 Jun 2007 22:54:57 -0400; valid = [28-Jun-2007 23:45:39 -0400]: /?_task=mail; changed = Thu, 28 Jun 2007 22:55:25 -0400; valid =
cleared sessions table, session_lifetime still enabled: [28-Jun-2007 23:48:00 -0400]: /; changed = Wed, 31 Dec 1969 19:00:00 -0500; valid = 1 [28-Jun-2007 23:48:00 -0400]: /?_task=mail; changed = Thu, 28 Jun 2007 22:57:46 -0400; valid =
cleared sessions table again, disabled session_lifetime: [28-Jun-2007 23:50:24 -0400]: /; changed = Wed, 31 Dec 1969 19:00:00 -0500; valid = 1 [28-Jun-2007 23:50:24 -0400]: /?_task=mail; changed = Thu, 28 Jun 2007 23:00:10 -0400; valid = 1 [28-Jun-2007 23:50:26 -0400]: /?_task=mail&_action=getunread&_remote=1; changed = Thu, 28 Jun 2007 23:00:10 -0400; valid = 1
-
Benjamin Bradley -
David Cramblett -
kmnair -
Thomas Bruederli