First, note that sessions do not expire -- web2py will keep the session as long as the client keeps returning the session cookie, so it's up to the client when to terminate the session (typically when the browser is closed). auth.settings.expiration does not determine when the session expires but when the login expires (i.e., after a period of inactivity, the user will have to log in again). Note, in order to avoid excessive session writing, session.auth.last_visit does not actually get updated on every single request -- it only gets updated if the time between the last visit and the current request exceeds 10% of the auth.settings.expiration time (so, about every 6 minutes with a one hour expiration).
As for the @service.jsonrpc requests, are those requests accessing an action that requires authentication, and if so, are you authenticating via a session cookie? If not, then those calls would not affect the session or the Auth login expiration. Anthony On Tuesday, January 15, 2013 8:27:04 AM UTC-5, Daniel Gonzalez wrote: > > FYI: > > Regarding my last two questions: the expiration is set in auth.settings, > but since I was using the session in memcache and the default_time_expire > in memche is 300 seconds, what I think is happening is that the session in > memcache is expiring, even though the session in auth.settings is not. > > That means no data can be recovered from memcache for the session, and > thus the session expires. > > I see several problems here: > > - the memcache session does not get updated, even though I am doing > accesses (in this case @service.jsonrpc accesses). I mean, this key should > be refreshed in memcache since I am accessing it (its ttl must be reset). > Just reading the session is not enough: it must be updated too, otherwise > it will expire! > - auth.settings.expiration is not useful if the memcache time_expire > is smaller > - session.auth.last_visit does not get updated in @service.jsonrpc > accesses > > Or maybe I am misunderstanding the expiration concept: it could be that > only login actions are supposed to refresh the session. > > But this looks a bit strange to me: as long as the client is sending > requests, the session should remain active! Whenever an *inactivity* > (meaning, no requests at all) period longer than auth.settings.expiration > has passed, the session should expire. Is this how things should work with > the current implementation? > > > On Tuesday, January 15, 2013 1:26:48 PM UTC+1, Daniel Gonzalez wrote: >> >> And even worse: I am setting, for testing: >> >> auth.settings.expiration = 3600 * 24 * 30 # one month >> >> But the session is expiring after 5 minutes anyway! What is happening >> here? >> >> On Tuesday, January 15, 2013 12:14:59 PM UTC+1, Daniel Gonzalez wrote: >>> >>> And a related question: my session is expiring after 5 minutes (300s). I >>> am not setting the expiration time, and the default in >>> Auth.default_settings.expiration is 3600. >>> >>> Where is the 300 coming from!?!? >>> >>> On Tuesday, January 15, 2013 11:57:03 AM UTC+1, Daniel Gonzalez wrote: >>>> >>>> Thanks Niphlod, >>>> >>>> I am now using: >>>> >>>> - session.auth.expiration >>>> - session.auth.last_visit >>>> >>>> And I have realized about one (at least for me) unexpected thing: >>>> accessing @service.jsonrpc controllers does not >>>> reset session.auth.last_visit. Is this intended? >>>> >>>> On Tuesday, January 15, 2013 11:43:11 AM UTC+1, Niphlod wrote: >>>>> >>>>> session expiration is managed by auth.settings.expiration ... >>>>> >>>> --
