I see. You are differentiating between login and session, and I guess I understand the distinction. I have verified the service.jsonrpc calls, and they indeed update last_visit.
The open issue is still expiration of the data in memcache, in combination with the auth.settings.expiration. I think this is not well integrated: if the memcache data expires, that's it. No matter how big auth.settings.expiration is, expiration of the data in memcache will force the login to expire. On Tuesday, January 15, 2013 3:08:38 PM UTC+1, Anthony wrote: > > 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 ... >>>>>> >>>>> --
