Session expiration issues

[ramgs]

Hello,

I recently set-up Roundcube 1.1.3 system on a CentOS 6.7 machine. I tested things a fair bit for a few weeks, and the system is live now. Users are happy with it, and most things seem to be running fine. We're using https / ssl (with force_https=true and the default_host=ssl://hostname and default_port=993).

However, some little issues are getting to me. Apologies if these are silly ones with simple fixes.

1) Expected behaviour: I login to the mail system. Then I open another browser tab/window and type the address of the login page. This would automatically take me to my Inbox. I can work in both windows.  Found during testing, with https as far as I can recall.

New behavior (in live system): From the other browser tab/window, I now get the login page. What's more, when I click on anything in the original window, or wait for the next refresh, it shows an error message ("Your session is invalid or has expired") and goes to the login page . I saw this behaviour in Firefox and Safari.

I can't understand why this occurs. I've tried a few things --- turning off plugins, checking the db and php timezones, cleaned cache and cookies, tried some php options in the roundcube's httpd config --- but I don't see indications in the roundcube logs of what I must do to to get back the original. Could anybody help? I'm happy to provide info. to help diagnose this.

Please note: All appears to work okay if I use the persistent_login plugin and check the "keep me logged in" option while logging in. I can't turn off force_https / ssl / other https setting as the system is live.


2)  I had logging turned in config.inc.php. I see these sorts of messages every few minutes in logs/session:

[Timestamp]: <3s1ghvmr> Session auth check failed for 3s1ghvm....
[Timestamp]: <3s1ghvmr> Send new auth cookie for 3s1ghvm....

Are these normal? Or are they indicative of the problems I see in point 1 above?

Hope this is a new question. I have searched roundcubeforums for topics along these lines, but didn't come by any.

Any help would be appreciated. Thanks!

[ramgs]

Hello.

My message above seems to have elicited no response yet. Could someone please reply? I just want to be sure that what I'm seeing is the expected behaviour.

Thanks very much.

[SKaero]

1. The behavior you saw while testing would be the expected behavior, seems like you have some sort of session problem on the live system.
2. There indicative of the session problem, you shouldn't be seeing that normally.

[ramgs]

Thanks for your reply, SKaero.

Could you suggest what I could check to pinpoint the cause?

Please note that I've already tried things I saw in other threads in this forum: turning off plugins, checking the db and php timezones, cleaned cache and cookies.

Just a thought: As I had written earlier, the test system had a different hostname and ip address, so all those things were changed before we went live. That included a change of the hostname containing lines in config.inc.php. Is it possible that some aspect of the Roundcube might be still "looking for" the test system?

Thank you.

[SKaero]

Try to compare your php configuration and web server configuration between the two servers and see what is different. Sessions are stored in the Roundcube database so changing the config shouldn't have any effect.

[ramgs]

Thanks for your reply, Skaero.

Was busy, but I'm now able to spend a little time on this.

I didn't change anything in php.ini. In the RC .htaccess, I didn't touch anything there either.

The thing of note is that I've put RC outside the Documentroot. For this, I've put the usual Alias  ("/webmail" pointing to the actual path) in the httpd config. I must admit that I might be mixing things up with a still older test system (than the one I write about in my first post on the topic) where RC was inside the Documentroot.

I chanced upon the session.cookie_path setting in  the .htaccess file. It is set to the default value, which becomes "/". I saw some old entry in the RC discussions that this cookie path must be set to the path where RC resides. See:http://trac.roundcube.net/ticket/1486456.  I tried that but it doesn't work; I can't even log in. I tried using /webmail as well. In this case, the system lets me log in, but the session gets killed when I try to type the webmail address on another browser tab.

Am I going in the right direction? Anything else I can try?

Thanks!

[SKaero]

I don't think moving the Roundcube document root should have an effect. Does running Roundcube in document root make it work?

[ramgs]

Probably, but I can't be sure. Since the system is live, I wouldn't want to shift RC to being inside documentroot to check this point.

[SKaero]

Why don't you make a copy of Roundcube and put it all in a public folder, something like "testrc" to see if that works correctly.

[ramgs]

Ahh .. should've tried that. Tried it now, but the problem persists.

[SKaero]

Are the sessions showing up in the Roundcube database?

[ramgs]

Seems so. Here's a clip from the output of the session table (sess_id, created, changed).

| 7u3hovlt44uk81vfpk9ncbl415 | 2016-01-29 11:46:49 | 2016-01-29 13:22:24 |
| 9u5b0a0qna8i7f2o73dacqipd1 | 2016-01-29 12:49:48 | 2016-01-29 12:49:48 |
| bdcje8vrpuu0pjj8gm535gh664 | 2016-01-29 12:54:02 | 2016-01-29 12:55:40 |
| bo1a3d11e39pp4ev80dcv500f4 | 2016-01-29 12:47:21 | 2016-01-29 12:49:38 |
| bsqpnttbmpa6bmfst536g9acp5 | 2016-01-29 11:31:53 | 2016-01-29 12:43:21 |
| c264ahlqrp1l9m33tqidq5nsc0 | 2016-01-29 11:34:31 | 2016-01-29 12:46:07 |
| d5v4bbvg67jrtsnelgc94c89c1 | 2016-01-29 12:43:57 | 2016-01-29 13:24:03 |


For these and other sessions, there here are many entries in logs/session of the following sort.
I've clipped the long strings.

[29-Jan-2016 11:53:32 +0530]: <7u3hovlt> Session auth check failed for 7u3hovlt....; timeslot = 2016-01-29 11:50:00
[29-Jan-2016 11:53:32 +0530]: <7u3hovlt> Send new auth cookie for 7u3hovlt....: S1c639738f....

[SKaero]

Have to tried increasing the session_lifetime in the Roundcube config?

[ramgs]

The default was 10 minutes for session lifetime. I changed that to 60 mins. Expectedly, I see fewer entries in the logs.

I was about to post something about the sql log and the php configuration. But I noticed something that I didn't bother to try before. Let me spell it out in detail.

Please note first that I have put force_https to true in the config file. The intention was to make the browser go to https for people like me who don't like to go click on a webpage link but type the URLs directly instead. I had previously tried use_https, but that didn't do so (as far as I can recall); presently,  this setting is false.

Typing http://serveraddress/webmail takes me to the login page in https mode. Once I log in, I've been presuming that typing the same would suffice to show me my inbox. Every time I tried this, I'd get logged out with an invalid or expired session message.

However, after logging in again and shifting to another tab, I lazily tried the browser suggestion (something I usually refuse to try) which was https://serveraddress/webmail/?_task=mail&_mbox=INBOX. That took me me straight in.

Puzzled, I then tried https://serveraddress/webmail. I went to my inbox. Then I changed back to http. I got logged out.

After I log in again, when I click on the link on my domain's website to the mail server login page (this link has https in the href value), I was taken to the inbox.

I've tried the above a few times from Safari and Firefox (with location bar suggestions turned off), and it seems to be consistent. The address I typed in the location bar was defaulting to http instead of https.

I suppose I've found a workaround to my original problem. I'm not sure I should call it a fix just yet, because I expected force_https of RC change the http://... to https://... whether a user session was active or not.

Have I missed something?

Thanks for patiently reading through the above!

PS -- By the way, what would it look like in the sql logs or some other RC log when someone is logs out normally or gets logged out due to session expiration? I ask this for I don't see something obvious there pertaining to the logouts I've experienced to the above problem.

[SKaero]

I can't say why force_https only works when the user isn't logged in but it specifically setup that way so its not a bug. I guess I'd recommend forcing ssl at the web server level.