Setting Session Timeout?

234 views
Skip to first unread message

Ewan

unread,
Jul 1, 2009, 5:47:38 AM7/1/09
to Lift
I have recently started using a SessionVar and am quite happy to have
the session wiped after some predefined interval. As an experiment I
changed the session timeout in the web.xml a la Java Servlets but this
had no effect running on jetty and since I have read that a SessionVar
is not just a wrapper around javax.servlet.http.HttpSession. My
question is then how can I configure the timeout interval?

-- Ewan

marius d.

unread,
Jul 1, 2009, 7:32:49 AM7/1/09
to Lift
LiftSession is bound to HttpSession through HttpSessionBindingListener
and HttpSessionActivationListener

This means that when the HTTP session terminates LiftSession will also
terminate. To verify your SessionVar that the session was purged you
can implement

override protected def onShutdown(session: CleanUpParam): Unit = {
...
}

where in case of SessionVar the session parameter is really a
LiftSession.


The LiftSession timeout is given by
HttpSession.getMaxInactiveInterval ... if that period is exceeded the
LiftSession is unbound from the HttpSession. Does not necessary means
that the HttpSession is removed by container ust that LiftSession is
terminated.


But is the problem the fact that HttpSession expired but you still had
the context in the SessionVar?

Br's,
Marius

Ewan

unread,
Jul 1, 2009, 7:42:36 AM7/1/09
to Lift
Thanks Marius

I basically wound the session timeout down to 5 mins in the web.xml
and left it for about 30 mins but the sessionVar was still full. Even
after some hours of no use it was the same. There is this constant
ajax_request pinging going on - related?

-- Ewan

marius d.

unread,
Jul 1, 2009, 7:59:33 AM7/1/09
to Lift
You answered your own question :) ... Yes that is Lift GC mechanism.
You can of course turn it off in Boot by calling ....
LiftRules.enableLiftGC=false but I would not recommend it.

Is there a real use case why you need this or just tying to figure out
how Lift works ?

Br's,
Marius

Ewan

unread,
Jul 1, 2009, 8:08:12 AM7/1/09
to Lift
My use case is that I want to "save" anonymous users' (users that have
not logged on or registered) baskets in the session and don't care if
they are removed after a period of inactivity. In fact I would like
the session to be expired after a while to encourage the user to sign
up which if they do they get the benefit that the basket is persisted.

--Ewan

marius d.

unread,
Jul 1, 2009, 9:00:30 AM7/1/09
to Lift
Well I think I can commit something very simple that could help you,

Currently session expiration mechanism considered only the time
threshold ... but the lift GC is keeping it alive. So we can have
LiftSession#terminateHint function that just marks a flag on this
LiftSession. SessionMaster can consider this and purge the session
properly at the next sessions scan. So you can have an actor where
you're sending messages via ActorPing such as:

ActorPing schedule(MyActor, Purge(S.session), 120 seconds)

When you receive the Purg message on the received LiftSession just
call session.terminateHint. (Note that S.session is a Box
[LiftSession])

The questions would be when am I going to do this scheduling? ... Well
probably right after you are setting a value on your SessionVar.



If someone has any objections about this please do let me know.
Otherwise I could probably commit this today.

Br's,
Marius

David Pollak

unread,
Jul 1, 2009, 12:20:02 PM7/1/09
to lif...@googlegroups.com
Ewan,

It seems that you've done your tests with a browser open to a page in your Lift app.  It seems to me that you don't want to time out a session unless the user's browser is no longer looking at a page in the app.  Is this in line with your expectations/use case?

Thanks,

David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Ewan

unread,
Jul 1, 2009, 3:24:52 PM7/1/09
to Lift
Hmmmm I understand the issue/feature now... where by if the page
remains open then the session is kept alive by the ajax request which
is a feature and it could be argued that for almost all cases this
would be what is required. I believe there is a use case for wanting
the session to expire after a predefined interval though - thinking
secure apps such as banking or email. I know my bank irritates the
hell out of me by "logging me off" after a period of inactivity though
this might not be implemented via HttpSession but instead they persist
a timestamp of the last request and compare with the current request
time.

My app requirements can be changed to fit the current method but I can
imagine that there would be need for other projects to implement
expiration as defined above.

--Ewan
> Beginning Scalahttp://www.apress.com/book/view/1430219890

David Pollak

unread,
Jul 1, 2009, 3:34:28 PM7/1/09
to lif...@googlegroups.com
On Wed, Jul 1, 2009 at 12:24 PM, Ewan <eha...@gmail.com> wrote:

Hmmmm I understand the issue/feature now... where by if the page
remains open then the session is kept alive by the ajax request which
is a feature and it could be argued that for almost all cases this
would be what is required.  I believe there is a use case for wanting
the session to expire after a predefined interval though - thinking
secure apps such as banking or email.  I know my bank irritates the
hell out of me by "logging me off" after a period of inactivity though
this might not be implemented via HttpSession but instead they persist
a timestamp of the last request and compare with the current request
time.

There are ways to do this in Lift (both with client-side JavaScript which would be my preference and with some server-side interception of requests along-side a timer).

At least BofA does it with a client-side timer that pops up a JS window.

Anyway, if you wanted to explicitly time out a session due to inactivity, it's possible and not overly difficult.
 



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Reply all
Reply to author
Forward
0 new messages