On 01/23/2010 11:32 AM, Marius wrote:
Well that just the standard session behavior but if you want
JSESSIONID in the URL yu should probbaly turn off cookies in Jetty (or
whatever container you have). Thus the URL's from the page would
be something like:
On Jan 24, 9:29 pm, Nolan Darilek no...@thewordnerd.info wrote:
On 01/23/2010 11:32 AM, Marius wrote:
Well that just the standard session behavior but if you want
JSESSIONID in the URL yu should probbaly turn off cookies in Jetty (or
whatever container you have). Thus the URL's from the
Lift session management works based on session id denominated by
cookies or url-rewriting.
However Lift support stateless requests processing. You could look
into LiftRules.statelessDispatchTable for having scala functions
process your request and then return a LiftResponse, or
Yeah, certainly I can duplicate the access token stuff from the Ruby
port and set up a scheduled function to clean them out every half hour
or so. I just wondered if I could hook into the session infrastructure
since a) that already does exactly what I need and b) I don't need
sessions for
LiftSessions have nothing to do with logins; they are bound to the
container's HTTP session. But in a JEE container this is bound with
JSESSIONID and if I understood correctly you don't want that.
LiftSession.scala manages sessions in Lift.
Br's,
Marius
On Jan 23, 5:21 pm, Nolan Darilek
On 01/23/2010 09:34 AM, Marius wrote:
LiftSessions have nothing to do with logins; they are bound to the
container's HTTP session. But in a JEE container this is bound with
JSESSIONID and if I understood correctly you don't want that.
I think that I do, but I don't know for sure. Basically,
On Jan 23, 7:06 pm, Nolan Darilek no...@thewordnerd.info wrote:
On 01/23/2010 09:34 AM, Marius wrote: LiftSessions have nothing to do with
logins; they are bound to the
container's HTTP session. But in a JEE container this is bound with
JSESSIONID and if I understood correctly you don't
