On 07/27/2012 10:43 AM, Hugh Brock wrote:
Here is the agreed feature description for session timeouts,
captured
from freenode/#aeolus:
There is an admin setting for session time in a config file, and...
<jayg> then we check after that time to ask if they are there
(This could mean "pop up a javascript warning)
<jayg> if no response after 30 seconds, log them out
<jayg> feature described
<hewbrocca> And
<hewbrocca> what resets the timer?
<hewbrocca> Do we have a way to differentiate backbone refreshes from
real
user requests? [11:25]
<matty_dubs> Non-Backbone activity == "activity"? Is that fair?
<jayg> a page refresh resets, I would think - or, clicking 'yes, I am
still
here'
Seems to me we would do this in two stages:
1. Implement the timeout itself, ignoring backbone requests and
reading the desired time before session expiration from a system
configuration setting
2. Implement a "warning, you're about to timeout" dialog. This could
be entirely client-side, or it could be a backbone request to the
server for time-before-expiration
Is this sufficient?
--Hugh
This seems about right to me. To clarify 1) -- ignoring backbone
requests means "backbone requests don't count as activity, and sessions
time out even while pages are being auto-refreshed", rather than
"ignoring the issue of backbone requests"
Also, we need to make sure whatever we do also properly expires/removes
API sessions (currently created once per API request, set to expire in 2
minutes).
I don't believe 2) is in scope for the current task, which should just
be 1). When we discussed this on the sprint planning call, 1) is
precisely what I was talking about doing here.
There's also probably a 3) -- at some point we need to stop creating a
new session on each API request, instead either doing something with a
session cache of sorts (i.e. maintain at most one API session per user),
or with tokens, or something else to avoid the LDAP lookup per request.
Scott