Roundcube Community Forum
Release Support => Pending Issues => Topic started by: timeuser on August 23, 2006, 10:12:58 PM
-
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.
-
set ip_check to FALSE and see if it happens again
-
Yep, it is still expiring my sessions with ip_check set to FALSE.
-
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 178)
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!
-
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.
-
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
-
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.
-
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.
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.
-
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.
-
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.
-
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.
do we have another lucky "session unexpectly expiring" winner? ;)
http://trac.roundcube.net/trac.cgi/ticket/1483986
are all these the same problem or just different problems/causes with the same symptom/effect?
-
LOL, its the same problem. Help me fix this and lets give a final solution.
-
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".
but if you only use 1 hour of your 3 hours, and then log off, your session will still be valid for 2 more hours, during which time a malicious person could reuse your cookies (either in the browser cache or sniffed on the wire). the purpose of the timeout is to make as small as possible that window of opportunity... or so i understand from the current code.
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.
file: program/include/session.inc
function: sess_read
code: $SESS_CHANGED = mktime();
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?
doesn't matter if they reset the cookie or not because the session is killed as soon as rcmail_authenticate_session() returns false (if "$valid = false") to index.php.
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.
no, i think it should be "$valid && ..." because we should only take the time to set the sessionauth cookie if the session is valid and not a POST and over 5 minutes.
as it currently is, why waste our time setting the cookie if the session is going to be killed shortly there after.
as you propose, why check request method or check relative time? when would everything after the logical or ("||") be true except when valid is also true (or so it appears)? and if you know both conditions are going to be true, why check both of them when only checking one of them would suffice.
too bad there aren't more comments in the source code or a design document that explains all this as i'm having to guess how some of this works together not having had enough time to study all the code.
Please help me find the $SESS_CHANGED var so we can figure out the entire thing.
hopefully the above helped. i don't feel it helped me any. i think i need to just study the code more in the context of the whole "application".
-
hopefully the above helped. i don't feel it helped me any. i think i need to just study the code more in the context of the whole "application".
Ya, but the piece of code that is corrupted is the one that I was talking in the post above.
-
Well .. I have the same problem but I can't completely enter my email.. whenever I put login information it says "Sessoin Expired"
that happens with me when using firefox and this problem just started when upgrading to 0.1 beta2 or above
I am using the same browser for previous version of RC and there is no problem so it is not cookie problem as I think
I tried the code mentioned above but with no good results :'(
there is no log appearing (actually no log file is created!! )
I turned the debug level to 8 but the log file -console- shows no problem .. also the mail log file !
This problem don't appear when I use IE as a browser....
-
Do you have the cookies enabled on your Firefox man?
-
I'm not much of a coder so I cant contribute much, but I did find something interesting when I was trying to track down this problem. I tried continuously monitoring the session created in the database and noticed that shortly before the user gets punted out of roundcube the session completely disappears from the database. So something like 30 seconds later the browser notices this and logs them out. As soon as they hit the login page a new session is created. What makes it even more maddening is that it seems to be sporadic on some users, consistent to others, and totally non-existant to the rest. Thanks to all who are trying to fix this, it's really a pain but it's great that people are working at it. Does this help any?
[edit]For the record this happens in all browsers, with all cookies enabled, etc.[/edit]
-
FYI:
The timeout issue also happens to me while just viewing my inbox contents.
Jz.
-
Having a hard time figuring out what to modify in the code from reading this thread. I'm not a saavy programmer or anything, so I'm doing my best to understand the flow of this thread.
Is the behavior supposed to be that the browser will send keep alives every 1 minute resetting the counter for the session on the server? The session lifetime variable in the main.inc.php is set to something like 5 (or maybe 15) minutes so that if the browser is closed without logging out the session will expire on its own? Sounds reasonable, except, when composing an email is it possible to keep sending keep alives? I guess it is as it auto saves the post as we're typing.
If this is the case, has anyone determined what the fix is? I saw a fix mentioned, but then read someone saying that the fix changes the behavior away from the above.
The session expiring is a bit frustrating. If no one has an answer, I guess this hack of a programmer, ok, I'm not a programmer, jst a hack, will try to trace through the code. But please, if you know of a fix, save me, and the RoundCube world from the results of my prodding.
Jz.
-
Having a hard time figuring out what to modify in the code from reading this thread. I'm not a saavy programmer or anything, so I'm doing my best to understand the flow of this thread.
Is the behavior supposed to be that the browser will send keep alives every 1 minute resetting the counter for the session on the server? The session lifetime variable in the main.inc.php is set to something like 5 (or maybe 15) minutes so that if the browser is closed without logging out the session will expire on its own? Sounds reasonable, except, when composing an email is it possible to keep sending keep alives? I guess it is as it auto saves the post as we're typing.
If this is the case, has anyone determined what the fix is? I saw a fix mentioned, but then read someone saying that the fix changes the behavior away from the above.
The session expiring is a bit frustrating. If no one has an answer, I guess this hack of a programmer, ok, I'm not a programmer, jst a hack, will try to trace through the code. But please, if you know of a fix, save me, and the RoundCube world from the results of my prodding.
Jz.
Hi, yeah well I made a hack for this issue, and it actually works and you wont have any more issues with the session stuff. How it works? well if you set up in the config file 20 minutes, the session will expire exactly 20 minutes after you log in, so it means that the script will not reset the expiration time never.
It works for me great, its just a minor fix so you can try it and let me know if it works for you. Have fun!
-
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 178)
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!
I used the fix posted by Heritz earlier in this thread and it stopped the session from timing out and sending me back to the login page. I am wondering if now that this is fixed is there a way to stop it from saving an auto-draft while you are composing a long message. I tested the fix by staying in the same message until it did an auto-draft twice. Now after I finally complete composing the message I have two seperate drafts of it. This is slightly annoying and I would rather it didn't save to the draft folder unless I tell it to.
A fix for this would be great but I can live with it if I really need to. I am not a programmer but I can follow great instructions like the fix posted by Heritz.
Thanks Heritz; have any ideas on the auto-draft question.
-
Hello there,
Well, actually, I am not using this application anymore since I've noticed that it has many errors and problems at this time. I am waiting for the next major release to start using it again because I just can't afford all my clients reporting me errors and stuff.
I am sorry about not having any suggestion for you about the auto-draft thingy but I am pretty sure that someone in this forum will help you about it. Also, you can check the SVN repository to check if any SVN version has a fix for that issue.
Have a nice day! :)
-
I have a user who is having this same problem.
They log in fine, but within 5 seconds they get a message that says "your session is invalid or expired." It then kicks them back out to the webmail login page.
However when I log in for them using the same username and password, it works fine with no logout.
Can someone please tell me if this issue has been resolved?
-
It is not a great solution, but it seem to solve the problem.
I deactivate the auto draft save, changing the time in app.js (program/js) like this
this.env.draft_autosave = 30000000; // seconds
original value is 300 seconds.
-
As I have no need for session expiration - I decided to come up with my own little "fix" for this issue - as I also encountered it.
This fix will stop the session from expiring automatically by stopping the function killing the session from being processed by the script.
It also disables the "keep alive" code provided, as I noticed that when this is processed too often it actually stops the feature working, at least on my server. Clicking "logout" still kills the session as it should do.
Note: make sure to click logout after finishing, otherwise you may encounter problems when using this!
This fixes this issue with roundcube on at least IE6 and Firefox v2.0.0.2
It requires editing two files, simply follow the instructions below.
Open program/js/app.js
goto line 285 and find:
// start keep-alive interval
this.start_keepalive();
};
// start interval for keep-alive/recent_check signal
this.start_keepalive = function()
{
if (this.env.keep_alive && this.task=='mail' && this.gui_objects.messagelist)
this._int = setInterval(this.ref+'.check_for_recent()', this.env.keep_alive * 1000);
else if (this.env.keep_alive && this.task!='login')
this._int = setInterval(this.ref+'.send_keep_alive()', this.env.keep_alive * 1000);
}
replace with this:
// start keep-alive interval
//this.start_keepalive();
//};
// start interval for keep-alive/recent_check signal
//this.start_keepalive = function()
// {
// if (this.env.keep_alive && this.task=='mail' && this.gui_objects.messagelist)
// this._int = setInterval(this.ref+'.check_for_recent()', this.env.keep_alive * 1000);
// else if (this.env.keep_alive && this.task!='login')
// this._int = setInterval(this.ref+'.send_keep_alive()', this.env.keep_alive * 1000);
// }
This will stop the keepalive/auto message checking functions. Although this may not be needed, I did so as I noticed sometimes it stopped checking for messages successfully if it was checking for messages via this function.
Open index.php
goto line 175 and find:
// check session and auth cookie
else if ($_action!='login' && $_SESSION['user_id'])
{
if (!rcmail_authenticate_session() ||
($CONFIG['session_lifetime'] && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < mktime()))
{
$message = show_message('sessionerror', 'error');
rcmail_kill_session();
}
}
replace with this:
// check session and auth cookie
else if ($_action!='login' && $_SESSION['user_id'])
{
if (!rcmail_authenticate_session() ||
($CONFIG['session_lifetime'] && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < mktime()))
{
//$message = show_message('sessionerror', 'error');
//rcmail_kill_session();
}
}
This stops roundcube killing the session, and displaying the session expiration message.
Hope this is useful to someone!
~Ben
-
Thanks for the tip btcentral. Although I think your suggested commenting in app.js might cause errors because you commented out '};' which closes 'this.init = function()' starting on line 94.
I recommend only commenting out the line 'this.start_keepalive();'. You don't need to comment out the function when you comment out the only call to it.
Also, further to this issue, I looked in my error file and it's full of these errors:
[03-Mar-2007 21:37:10] PHP Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent in [...]/webmail/program/include/main.inc on line 89
[03-Mar-2007 21:37:10] PHP Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent in [...]/webmail/program/include/main.inc on line 89
[03-Mar-2007 21:37:10] PHP Warning: Cannot modify header information - headers already sent in [...]/microugly.com/webmail/program/include/main.inc on line 97
[03-Mar-2007 21:37:10] PHP Warning: Cannot modify header information - headers already sent in [...]/microugly.com/webmail/program/include/rcube_shared.inc on line 132
It seems that header information being sent early may be the overall cause of sessions not being set correctly. But I wouldn't know where to begin looking to find code that might be outputing information early. Are others seeing similiar error messages?
-
Ugh, I am still having errors with the thing telling me my session has expired! It only happened to me once or twice after I had thought I'd "fixed" it before with one of the solutions that was posted here (setting something to 0), but yesterday and today it happened to me several times, the last of which it didn't even save my draft even though the autodraft said it was saving it!
Do these entries in index.php have anything to do with this problem:
ini_set('session.gc_maxlifetime', 21600);
// increase maximum execution time for php scripts
// (does not work in safe mode)
@set_time_limit(120);
// not logged in -> set task to 'login
if (empty($_SESSION['user_id']))
{
if ($REMOTE_REQUEST)
{
$message .= "setTimeout(\"location.href='\"+this.env.comm_path+\"'\", 2000);";
rcube_remote_response($message);
}
$_task = 'login';
}
Or how about these in /program/js/app.js:
// default environment vars
this.env.keep_alive = 60; // seconds
this.env.request_timeout = 180; // seconds
this.env.draft_autosave = 300; // seconds
// start interval for keep-alive/recent_check signal
this.start_keepalive = function()
{
if (this.env.keep_alive && this.task=='mail' && this.gui_objects.messagelist)
this._int = setInterval(this.ref+'.check_for_recent()', this.env.keep_alive * 1000);
else if (this.env.keep_alive && this.task!='login')
this._int = setInterval(this.ref+'.send_keep_alive()', this.env.keep_alive * 1000);
}
// use an image to send a keep-alive siganl to the server
this.send_keep_alive = function()
{
var d = new Date();
this.http_request('keep-alive', '_t='+d.getTime());
};
// send periodic request to check for recent messages
this.check_for_recent = function()
{
if (this.busy)
{
this.send_keep_alive();
return;
}
this.set_busy(true, 'checkingmail');
var d = new Date();
this.http_request('check-recent', '_t='+d.getTime());
};
Or this in /program/include/session.inc:
// garbage collecting function
function sess_gc($maxlifetime)
{
global $DB;
// get all expired sessions
$sql_result = $DB->query("SELECT sess_id
FROM ".get_table_name('session')."
WHERE ".$DB->unixtimestamp('now()')."-".$DB->unixtimestamp('changed')." > ?",
$maxlifetime);
$a_exp_sessions = array();
while ($sql_arr = $DB->fetch_assoc($sql_result))
$a_exp_sessions[] = $sql_arr['sess_id'];
if (sizeof($a_exp_sessions))
{
// delete session cache records
$DB->query("DELETE FROM ".get_table_name('cache')."
WHERE session_id IN ('".join("','", $a_exp_sessions)."')");
// delete session records
$DB->query("DELETE FROM ".get_table_name('session')."
WHERE sess_id IN ('".join("','", $a_exp_sessions)."')");
}
// remove session specific temp dirs
foreach ($a_exp_sessions as $key)
rcmail_clear_session_temp($key);
// also run message cache GC
rcmail_message_cache_gc();
return TRUE;
}
I just don't want to touch anything and mess anything up! :P
-
It seems that header information being sent early may be the overall cause of sessions not being set correctly. But I wouldn't know where to begin looking to find code that might be outputing information early. Are others seeing similiar error messages?
May be related to bug 1483926 http://trac.roundcube.net/trac.cgi/ticket/1483926 (http://trac.roundcube.net/trac.cgi/ticket/1483926) - I can't prove it (can't duplicate "Session Expired" on demand) but I have had neither the "Cannot modify header information" error nor the "Session Expired" message in the two weeks since applying the patch in that bug.
-
The only error messages I'm getting in my error log, if it helps anyone, are that it is saying it can't delete a message in Drafts (but I wasn't trying to delete one, so that's weird!). Nothing about headers, but I am getting logged out.
By the way, I have never been able to locate my cookie in my cookies folder when I'm logged in. I just tried it again and kept refreshing the cookies folder and there is no cookie showing for my RoundCube mail site. ???
-
Session Expired BEFORE login.
WARNING: PHP gives unexpected results when comparing two integers that differ by an amount greater than the largest positive integer, typically 231-1. A safer way to compare large integers is to cast them to floating-point numbers. The following example illustrates this point:
$var1 = -2106036000; // 16/08/1902
$var2 = 502808400; // 24/08/1984
// $result is assigned false
$result = $var1 < $var2;
// $result is assigned true as expected
$result = (float) $var1 < (float) $var2;
Even floating-point numbers can overflow. To manipulate numbers of arbitrary precision, the BCMath library should be considered.
/program/include/main.inc
line 236
if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && $SESS_CHANGED + $CONFIG['session_lifetime']*60 < time())
Change to
if (!empty($CONFIG['session_lifetime']) && isset($SESS_CHANGED) && (float)($SESS_CHANGED + $CONFIG['session_lifetime']*60) < (float)(time()))
Maybe such error in code in some other place?
-
Hi. Installed roundcube and had the session expired at login problem.
After a little investigation I found the solution. Maybe it can help other users.
Installed Roundcude on a win 2003 server with iis connecting to mysql on a old sun sparc with linux.
I found that roundcube inserts records in the session table with database server date.
In my case database server time was 30 minutes less than iis and browser date.
Changed database server date and the problem is fixed.
Well. Didn't have the time to browse roundcube code but I think it's a wrong way to handle session expiration.
-
I also kept getting "session expired" errors after upgrading to 0.1-stable. I could login, view an email or two, and would then be disconnected after a few minutes.
In my case, the problem was caused by bug #1484819 http://trac.roundcube.net/ticket/1484819 (http://trac.roundcube.net/ticket/1484819). After applying the regression described there by sirocco, everything is working again.
Looking at the log of my IMAP server (CommuniGate Pro), I can see that Roundcube would attempt to login via IMAP using CRAM-MD5 authentication, fail, fall back to LOGIN authentication, succeed, and perform one operation. This would repeat for several operations, until finally the IMAP server says "too many failed login attempts" and blacklists the IP (localhost) for a short time, so the LOGIN authentication fails as well. Roundcube would then, understandably but incorrectly, report "session expired".
This may be one of several reasons why so many people are seeing the "session expired" problem with the new release.
Franzzup
-
Hi. Installed roundcube and had the session expired at login problem.
After a little investigation I found the solution. Maybe it can help other users.
Installed Roundcude on a win 2003 server with iis connecting to mysql on a old sun sparc with linux.
I found that roundcube inserts records in the session table with database server date.
In my case database server time was 30 minutes less than iis and browser date.
Changed database server date and the problem is fixed.
Well. Didn't have the time to browse roundcube code but I think it's a wrong way to handle session expiration.
I had the same problem, with only 10 mins time difference.
After using NTP to sync the hosts, everything is back again.
There should be something wrong on how the session date is created. It should not rely on the client's time...
-
Hello
in last stable build 0.6, some of my users are still suffering from session timeout.
What's finally the resolution for this annoying issue ?
thank you
-
Hello
in last stable build 0.6, some of my users are still suffering from session timeout.
What's finally the resolution for this annoying issue ?
thank you
As I just encountered it myself when composing a longer message (and lost a lot of text) - same question. RC 0.5.4