Session Timeout on Compose Screen

[afladmark]

When I sit on the compose screen for a while, (on my system its less than 15 minutes) I eventually get thrown out of RoundCube (I think during an auto-save) with an error that my session has expired or is invalid. Shouldn't the Draft auto-save be keeping my session alive?

[Lou]

I would think this is working as designed. Log in to RC, start writing a message and walk away. I want RC to log me out after my inactivity lasts too long.

You can always change the session timeout delay if you find it is too short.

[afladmark]

I guess it's an interesting question in the new AJAX world... The reason I think I disagree is that the page is actively connecting back to the server every minute to save my draft in progress... so technically, I'm not idle... a.) from the AJAX app perspective -- even if I'm typing constantly for 15 minutes it does it (sometimes it takes more than 15 minutes to write a message!; b.) from the PHP/server-side perspective, a connection is made every 1 minute..

The other perspective I'll offer is this... In RoundCube, I can sit, logged in in the Inbox view. The page checks for new messages every few minutes... This page stays logged in for HOURS with no interaction from me... Why apply a different standard to one page vs another..

No?

P.S. When you say session timeout delay, are you referring to PHP's session garbage collection.. or is there a setting for RoundCube itself? This might be a reasonable temp fix...

[MarekR]

I think, there is an easy way to solve this problem. Just let the compose screen to open in separate window. This solution have one more adventage: you can compose several messages at one time.

[patrys]

The correct behaviour is to make the AJAX postback extend your session. It sometimes takes half an hour to compose an email (having to check several sources for data the other person is requesting).

[entropy]

I'm running roundcube as an alternative webmail for a medium size college campus and have been having lots of problems with the session expiring/invalid and logging the person out, sometimes after as little as 2 minutes. It seems to be selective by the account and not the IP address. Some people's account do this and other's dont but I can find nothing to distinguish the two. Any Ideas?

[entropy]

Addion to my above post: I've done a bunch more testing and it seems that it is not account based after all and does seem to be oddly random. I have found an additional symptom by watching the database entries for sessions:

Just before roundcube punts the user to the login page the session disapears entirely from the table in the database. When they get kicked out it reappears with a new create time and a changed time of a few seconds later. Hope this helps track it down.

[thomasb]

I guess the changing auth cookie causes a validation failure.
r338 includes some changes to the authentication function as well as a debug log for failed session validations. Please try it out.

[zyzzyvas]

I wanted to chime in here...I am having horrible problems with sessions expiring using 0.1-beta2. Usually happens while in the middle of composing a message, and no draft is saved. Have to retype everything...

Looking forward to a fix.

[olive@…]

Manually merging selected changes from [e170b4b7] into my 0.1-beta2 roundcube, it seems this bug is fixed. I've been logged on for 30+ minutes, and i left the composing window alone for most of the time, coming back to it only 3 times ; I haven't been disconnected so far.

Before the [e170b4b7] merge I felt very frustrated about beeing disconnected during composition of very long mails to my friends, and loosing most of the content of the mail (it disconnected during draft save)...

Now this seems fixed with [e170b4b7]. Note that I didn't merge everything from this patch, but only the relevant changes to *.session.* in all the files.

Thanks for pointing us to this fix.

[mkaatman]

This is no longer an issue with the latest SVN.

[dai]

I have 0.1-beta2.1 installed and have also the Session Timeout Problem ca. 6 minutes after starting composing a new mail. The first autosaving functions well and the message has been saved. Then comes "Your session is invalid or expired" and i'm logged out.
I have also increased the global Session timeout from 10 to 60 minutes. It doesn't help.

How can i fix this.

[thomasb]

This bug is fixed in the current SVN version. It remains in the bet but please not reopen it because of that.

You can set $rcmail_configsession_lifetime? = 0; to prevent timeouts.

[mankytongue]

The bug is still present in SVN version (current version in use is [02479770]).

'session_lifetime' is set to 0 as per the previous comment but it has no effect on this bug.

[cy23]

I have this behaviour sometimes when i get new email while composing. Maybe this helps.

[thomasb]

Marked #1484299 as duplicate of this bug. Lokks like it doesn't only affect the compose screen.

[fourat.zouari]

I can't replicate this bug on my local [518] version, i let the compose screen open for 1 day and nothing happens.
Can you provide for the moment, informations like :

• Steps-to-reproduce scheme.
• Environment details (OS/Apache version/PHP version/MySQL version)

[mcuria]

I've recently upgraded my 0.1b installation to the latest svn code, and reproduced this bug. After a few tests, I dropped the database tables (mysql), ran the initial db scripts, and the problem vanished.

So, I believe the problem is probably a bug in the upgrade scripts.

[imars]

I have a fresh install of 0.1beta2.2 here, no upgrade done, and I have encountered the problem. (Luckily the previous 1-2 saves to Drafts worked, so I only lost a paragraph or so.)

I run a FreeBSD 4 server, with MySQL 4.1.14 and Apache/1.3.34 (Unix) PHP/5.2.0.

[RealMurphy]

I just encountered the same problem with a fresh SVN checkout (552 IIRC). I started to type a message, I got the message that the draft was saved on the server (after the configured 180s) and after a few extra seconds the browser showed that my session expired and reloaded the log-in screen while I was still typing the message.

I'm running Ubuntu edgy on the server, sqlite backend, Apache 2.0.55 with PHP/5.1.6.

So far I have not yet tried to set the timeout to 0, that's the next step I'll try.

[thomasb]

Can you reproduce this with

$rcmail_config['ip_check'] = false;
$rcmail_config['double_auth'] = false;

Should work with the appropriate settings.

[RealMurphy]

Replying to thomasb:

Can you reproduce this with

$rcmail_config['ip_check'] = false;
$rcmail_config['double_auth'] = false;

Should work with the appropriate settings.

With these settings it seems to work fine (at least for me)!

[maharaja]

is there still a demand to fix this bug in 0.1beta?
because if so i can try to extract my patch which seems to work most of the time.

please inform me! (best thing would be via the mailinglist)

[thomasb]

What patch? Could you please share it with us?

[thomasb]

Close it for now. Please re-open with new details about the problem.

[maharaja]

i tried to isolate my patch - please take a look.

i take no guarantee that my patch won't undermine the
security which you tried to implement with the session handling :)

[maharaja]

roundcube session expiry patch with some logging