session times out

This issue has been tracked since 2021-11-09.

I am not sure if it is a bug, a configuration or related to the used openSUSE package, but I have the bahaviour since the update to roundcubemail 1.5

Before (1.4.x) I had a tab (FF) open with roundcubemail and it stayed open and in the tab I could see if a new mail arrived.

Now it loggs out after some minutes and I have to log in twice. The first try ends with a yellow warning bottom right "invalid entry. No data will be saved". Then the second try is ok.

(PHP 7.4.6)

CyberBotX wrote this answer on 2021-11-12

I've been experiencing the exact same problem since moving from 1.4.x to 1.5.x. My OS is FreeBSD, my PHP is 8.0.12 and my php.ini is mostly just the production version of php.ini with some minor changes, the only ones related to sessions would be whatever is recommended in roundcube's documentation (namely the PHP Configuration section of the Installation document on the GitHub wiki). I suspect this isn't a configuration issue but something wrong in roundcube itself.

CyberBotX wrote this answer on 2021-11-15

I forgot to point this out a few days ago, but my reason for thinking that something is wrong in roundcube is that I was also getting the problems before I upgraded my PHP to 8.0.12, when I was on PHP 7.3.32.

syncgw wrote this answer on 2021-11-18

Same problem with 1.5.0. See attached MITM trace.

twekkel wrote this answer on 2021-11-19

My guess; the Roundcube session lifetime is too short (or almost equal) compared to your Roundcube refresh setting (Settings > Preferences > User interface > Refresh).

I believe both are by default 10 minutes... so if you would increase the Roundcube session lifetime to e.g. 20 minutes, the browser session should stay alive. Timeout defaults in previous versions of Roundcube might have been different.

Two possible options/workarounds:

  1. Lower the Roundcube User interface refresh interval to e.g. every 5 minutes


  1. Extend the default session timeout, by adding/changing this setting

$config['session_lifetime'] = 20;

in config/

... hopefully this works out for you

dropfree wrote this answer on 2021-11-19

@twekkel thank you!
That seems to solve the issue for me.

(Settings > Preferences > User interface > Refresh) was and still is on 5 minutes
The session_lifetime entry was not existing in the config. I added the line as described and restarted apache to make sure the new entry is used.

Now for some time I am not logged out any more and seem to have the "old" behaviour back.

Thank you very much!

twekkel wrote this answer on 2021-11-19

Nice that it works.

I'm not sure if the current/default 1.5.0 behavior is a bug or a (security) feature, so better to leave this issue open for the moment.

syncgw wrote this answer on 2021-11-19


I tested it with different results. in RC 1.4.x I had no $config['session_lifetime'] in config/ I assumed it would be taken from config/ (which defaults to 10 minutes.

I followed your advice and added $config['session_lifetime'] = 20 to config/ My "Refresh" time is set to 3 minutes.

Behavior of RC didn't change - same results and behavior as posted by @dropfree.

dropfree wrote this answer on 2021-11-19

I fear i have to correct my last message.
I am still logged out, but much later - guess after 20 minutes now.
Maybe the refresh option is not working proper?

twekkel wrote this answer on 2021-11-19

As far as I can see the refresh is working perfectly, but it doesn't extend the session lifetime ... if this is intentional or a bug, I do not know.

Ever lasting sessions can be a security risk... but on the other hand a refresh that doesn't extend the session seems kind of pointless... I'd better leave this to the pros to answer.

CyberBotX wrote this answer on 2021-11-19

I'm not sure if the suggestion to change the refresh/session lifetime is what the problem is. I haven't changed my session lifetime so it is defaulting to the 10 from and my UI refresh has been on 5 Minutes this whole time, yet I still keep getting the session time out error. It isn't even consistent on how long it'll be before it times out, I've had times where it'll still be logged in for a bit over an hour, sometimes it'll be logged out in much less than half an hour.

alecpl wrote this answer on 2021-11-20

Two things here:

  1. The need to log in twice is a duplicate of #8194.
  2. I'm unable to reproduce the session expiration issue.

The session should not expiry itself. To make sure we send refresh and/or keep-alive requests (depending on the session lifetime and refresh interval settings). So, to investigate that you'd have to track the http requests in browser console. It might be that some of them do not reach the server or browser not sending the cookies. Of course, the issue might be somewhere else, e.g. in the session configuration/engine.

And you should test with all plugins disabled.

syncgw wrote this answer on 2021-11-20

Disabled all Plugins and created attached HAR file (FireFox). I setup a test system, so I can also provide you with test account data. Then you can check out yourself. If there is something like "private message" on GitHub, please let me now. Otherwise send me a mail to bug8303 [ at ] (temporary e-mail) and I will send you back login data.

tst.wb28.de_Archive [21-11-20 12-09-16]

dropfree wrote this answer on 2021-11-20

With Firefox 94.0.1 in troubleshooting mode http requests are all 200 and I have these errors in the browser console after login:

Message manager was disconnected before receiving Extension:ExtensionViewLoaded 2 ExtensionParent.jsm:1489
    observer resource://gre/modules/ExtensionParent.jsm:1489
    _releaseBrowser resource://gre/modules/ExtensionParent.jsm:1289
    shutdown resource://gre/modules/ExtensionParent.jsm:1284
    shutdown chrome://extensions/content/parent/ext-backgroundPage.js:107
    onShutdown chrome://extensions/content/parent/ext-backgroundPage.js:231
    ExtensionAPI resource://gre/modules/ExtensionCommon.jsm:358
    wrapper resource://gre/modules/ExtensionCommon.jsm:302
    emit resource://gre/modules/ExtensionCommon.jsm:329
    emit resource://gre/modules/Extension.jsm:2156
    shutdown resource://gre/modules/Extension.jsm:2872
    AsyncFunctionNext self-hosted:692
BackgroundUpdate: _reasonsToNotScheduleUpdates: Failed to check for Maintenance Service Registry Key: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIUpdateProcessor.getServiceRegKeyExists]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: resource://gre/modules/BackgroundUpdate.jsm :: _reasonsToNotScheduleUpdates :: line 243"  data: no] BackgroundUpdate.jsm:245
Error: Invalid autocomplete selectedIndex AutoCompleteChild.jsm:125:13
    get selectedIndex resource://gre/actors/AutoCompleteChild.jsm:125
Error: Invalid autocomplete selectedIndex AutoCompleteChild.jsm:125:13
    get selectedIndex resource://gre/actors/AutoCompleteChild.jsm:125
    observe resource://gre/modules/LoginManagerChild.jsm:194
NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "Invalid autocomplete selectedIndex" {file: "resource://gre/actors/AutoCompleteChild.jsm" line: 125}]'[JavaScript Error: "Invalid autocomplete selectedIndex" {file: "resource://gre/actors/AutoCompleteChild.jsm" line: 125}]' when calling method: [nsIAutoCompletePopup::selectedIndex] LoginManagerChild.jsm:194
    observe resource://gre/modules/LoginManagerChild.jsm:194
The Web Console logging API (console.log,, console.warn, console.error) has been disabled by a script on this page.
alecpl wrote this answer on 2021-11-21

These errors do not look relevant, but I would suggest to try with another browser or with all browser extensions disabled.

dropfree wrote this answer on 2021-11-21

Firefox in Troubleshoot Mode temporarily disables add-ons (extensions and themes), turns off hardware acceleration and certain other features, and ignores some customizations.
I tried Chrome 96 and Safari 15.1 (both without addons) all on MacOS Big Sure 11.6.x
On all browsers the session closes after the session_lifetime and do not keep alive by the refresh setting.

syncgw wrote this answer on 2021-11-24

I tried to get more information about the failing login after session has timed out. So I added a var_dump($auth); to index.php:122. The result is:

array(7) {
["host"] => string(7) "mail.fd"
["user"] => string(10) "[email protected]"
["pass"] => string(8) "password"
["valid"] => bool(false)
["error"] => NULL
["cookiecheck"] => bool(true)
["abort"] => bool(false)

syncgw wrote this answer on 2021-12-02

auto-logoff is annoying...

I found out, that in rcube.php:1041 the variable $token is

  • sometimes empty. $sess_tok is filled with Pfd09rqYvelMefcKeBUnb8z89Yw7IaHo.
  • sometimes JYxkdr11vSJxF39Kafy00o5rcKTq5bWE, but $sess_tok is filled with tCzQP0NIatOhCzH4LNPtknhfjh3k2gh3.

In line 1045 RoundCube return false for check_request(rcube_utils::INPUT_POST) which results in the "auto-logoff".

How can we find a solution?

syncgw wrote this answer on 2021-12-02

Please find attached session log, where you can see when session is dropped.

syncgw wrote this answer on 2021-12-10

Another approach:

  • On PHP running as "Apache 2.0 Handler" (local XAMPP) timeout does not happen.
  • On PHP running either as "FPM/FastCGI" or "CGI/FastCGI" (internet server) it happens.
CyberBotX wrote this answer on 2021-12-10

Well, I am experiencing the timeout with the PHP Apache 2.4 module. So I don't think that is the solution. I still say it is clearly something wrong with Roundcube's session handling.

alecpl wrote this answer on 2021-12-10

There's one change (besides some other more subtle changes) regarding session in 1.5, it is 39086d4. Maybe this will give you some hints for investigation.

syncgw wrote this answer on 2021-12-10

I reverted change 39086d4 (commented out added lines) and surprisingly session timeout disappeared. session table field were defined as described in roundcubemail/SQL/mysql.initial.sql. So problem could not be related to MySQL table structure. Could it be a problem of MySQL engine (my is ENGINE=InnoDB)?

Seems there is the source of the problem located.

CyberBotX wrote this answer on 2021-12-10

I use the SQLite engine myself and just now double-checked that all the tables in my database match the necessary schema, so I do not think it would be a database problem.

alecpl wrote this answer on 2021-12-11

So, before this commit expired sessions were not removed immediately and could be used after they expired. This commit changed that so expired session is removed immediately. The db schema is the same, there's an additional check.

Normally, this should not cause this issue, because the session is supposed to be kept alive, so the problem might be in the way we keep the session alive.

syncgw wrote this answer on 2021-12-11

How can I help tracking down the bug? Any additional information I can provide / perform any tests?

erdos4d wrote this answer on 2021-12-19

I just upgraded from 1.4 to 1.5 and have this issue. I used to have long running sessions in my browser and I had nothing configured to allow this. Now with 1.5 it appears that the default value of $config['session_lifetime'] = 10 is actually being obeyed and causing this issue. Increasing this value seems to fix it for me.

More Details About Repo
Owner Name roundcube
Repo Name roundcubemail
Full Name roundcube/roundcubemail
Language PHP
Created Date 2012-05-04
Updated Date 2022-09-20
Star Count 4564
Watcher Count 228
Fork Count 1510
Issue Count 279


Issue Title Created Date Updated Date