session times out

[dropfree]

Hi, 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]

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]

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.

[toteph42]

Same problem with 1.5.0. See attached MITM trace. Trace.pdf

[twekkel]

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

or

2) Extend the default session timeout, by adding/changing this setting

$config['session_lifetime'] = 20;

in config/config.inc.php

... hopefully this works out for you

[dropfree]

@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]

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.

[toteph42]

@twekkel

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

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

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

[dropfree]

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]

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]

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 defaults.inc.php 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]

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.

[toteph42]

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 ] wb28.de (temporary e-mail) and I will send you back login data.

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

[dropfree]

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.info, console.warn, console.error) has been disabled by a script on this page.

[alecpl]

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

[dropfree]

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.

[toteph42]

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) "t1@mail.fd" ["pass"] => string(8) "password" ["valid"] => bool(false) ["error"] => NULL ["cookiecheck"] => bool(true) ["abort"] => bool(false) }

[toteph42]

Hi, 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?

[toteph42]

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

[toteph42]

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]

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]

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

[toteph42]

Hi, 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]

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]

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.

[toteph42]

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

[erdos4d]

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.

[cbhp]

8431 looks good. I have the same issue with session expiration after 10 minutes with 1.5.2 when PHP's timezone (e.g. UTC) is different to the MySQL server's timezone (e.g. CET).

As workaround, I've configured date.timezone in my custom php.ini to be the same.

[dropfree]

A first test looks like the timezone config solves the session timeout issue for me as well. OS/mysql was CET and in php.ini was default UTC. Now both are the same and so far roundcubemail keeps the session. I will report if the session times out again.

[NotANormalNerd]

I have the same problem, but I am running the docker image (roundcube/roundcubemail:latest-apache) with sqlite. So this does not seem to be DB specific?

[alecpl]

Fixed.

[bombcheck]

Fixed.

Sure? Tried your commit above and the error still exists...

[NotANormalNerd]

I am using the the 1.6-beta docker image for 2 days now and can confirm that the bug still exists (roundcube/roundcubemail:1.6-beta-apache) sessions expire on the logon form and in the webmail UI.

[NullRien]

This error is still happening to me too, i tried using the fixes but nothing has changed the logout time