On Sun, 11 Aug 2013, Thomas Bruederli wrote:
Hmm, sessions should not expire while somebody has an active window and is still typing a message. This is the real issue that needs to be investigated and resolved. But you already mentioned that the memcache fix is applied in your deployment, right?
Yes. Further experimentation yesterday does suggest a difference in behaviour between the memcache and normal database code.
If I click Send and the session has expired using memcache session storage the browser just hangs with a spinning "Sending" icons, which is what I reported yesterday. The same experiment using database session storage appears to send the message successfully (which I don't quite understand if the session has expired: is there special handling?) and then bounce the user to the login page with a "session has expired" error. I think that this is what you are expecting to happen here.
A related curiosity in the client side Javascript:
It looks like that if you click Send without any network connection at all (I disabled wireless on my laptop a lot while testing the the KeepAlive stuff yesterday) then you end up with a stuck Sending spinner. Which is fine: the browser can't do much else at this point. However none of the buttons in the Roundcube user interface respond if you restore the network connection and try again, which is a little concerning.
If I force a page reload and the session hasn't timed out then Roundcube carries on its merry way, but you have lost the current draft message.
I haven't tried a variety of clients. The problem might be specific to Chrome running on my Linux workstations. This might be where the helper app that you mentioned would step into the rescue.
I imagine that is what is being reported here. While the KeepAlive stuff seems to be working, I imagine that it is quite common for people to close up their laptop and move to another room before continuing a message.
Aha!
Looking at my logs, I'm pretty certain that this is what is going on, at least in the two cases reported to me so far: there is a longer gap between KeepAlives than I would expect.
This would have worked with our old Webmail application, so people haven't adapted their behaviour. My workaround was to increase session_lifetime to 4 hours, to match the old Webmail's behaviour.