Claudio Kuenzler wrote:
On Tue, May 1, 2012 at 12:49 PM, A.L.E.C <alec@alec.pl mailto:alec@alec.pl> wrote:
Digging into session issues I've found this keep-alive thing a little bit overcomplicated and unclear. The keep-alive setting handles two things: session keeping and new-mail checking. Some plugins also bind to keep-alive to do some recurring actions (e.g. to display calendar alarms, etc.). I think we should split these functionalities. So keep-alive action should be used only for session keeping. In such case we need to execute keep-alive action only after some inactivity time (e.g. session_lifetime - 1min [or 5%]). It means timer should be resetted on every reequest. Also it means we don't need a separate config option, because the interval would be calculated from session_lifetime. For session_lifetime=0 there would be no keep-alive requests.Wasn't the whole keep-alive timer removed in change 6135 ?
Nope, that wasn't removed. I removed the separate request_timeout timer but set a timeout to the jquery ajax api instead.
By the way, since applying R6134 and 6135, the following entries are added every 5min to sessions log:
[01-May-2012 12:40:58 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 12:40:00 [01-May-2012 12:40:58 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: S53fabb9110e91180a0496334c87df7aac72d70d9 [...]
That's correct and I assume to have log_session enabled in config. The auth cookie is valid for 5 minutes (session_lifetime / 2) and is then replaced with a new value. That process is logged here for debugging purposes. The whole session auth cookie is meant to be an additional protection against session hijacking because it changes during a session whereas the actual session cookie doesn't.
~Thomas