[RCU] New Roundcube Deployment
dpc22 at cam.ac.uk
Sun Aug 11 19:23:29 CEST 2013
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.
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.
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.
David Carter Email: David.Carter at ucs.cam.ac.uk
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
More information about the users