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 <no...@thewordnerd.info> wrote: > 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 traditional logins. > > On 01/23/2010 02:49 AM, Marius wrote: > > > 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 > > > LiftRules.statelessRewrite for rewriting requests very early thus > > transforming them into some other forms. > > > Br's, > > Marius > > > On Jan 23, 4:52 am, Nolan Darilek<no...@thewordnerd.info> wrote: > > >> I'm porting an app I've written in Ruby over to Scala and Lift, and I'm > >> wondering if Lift and Java's sessions can accomplish what I'm attempting. > > >> The app is mostly XMPP-based, though there is a web interface for > >> configuration. Both run in the same process, because some changes from > >> the web interface need to be reflected instantly in the XMPP interface, > >> and I'd rather not have a separate message-passing layer out-of-process. > > >> Users don't log in with a username and password. Instead, they send an > >> XMPP command and are sent a temporary URL. The URL vanishes after a > >> certain timeout, and can also be reset by resending the command. > > >> In Ruby, I generate a GUID which I periodically time out, tracking last > >> access times via the web app. I'm wondering, though, if Lift's sessions > >> can achieve this? I'm not immediately sure where to look, but if anyone > >> could give me pointers for the following requirements, that'd rock. > > >> 1. Visiting the app without a session ID param shouldn't generate a new > >> session. Basically, index.html will just be mostly static, providing > >> info on the service itself. > > >> 2. If the "config" command is sent via XMPP, the bot should first search > >> all sessions for any matching the user's JID, destroying one if it > >> exists. It should then create another, passing the user back a URL to > >> the app with a jsessionid parameter. So I need to somehow associate > >> arbitrary properties with sessions and find one based on those. Note > >> that the sessions still need to be addressable via unique strings to > >> maintain some level of security. > > >> 3. Visiting a URL with a jsessionid parameter should whipe out any > >> sessions set in cookies. Actually, since the web configuration interface > >> is just two forms, I'm likely fine with disabling cookie-based sessions > >> entirely and just passing around jsessionids if that would make things > >> easier. > > >> Can anyone offer any pointers as to where to begin looking? Or am I > >> totally off base here? I tried glancing over LiftSession, but that left > >> me even more confused as to whether or not an XMPP app can create > >> sessions and pass off their URLs. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
