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.
