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 want that. > > I think that I do, but I don't know for sure. Basically, I want to > associate properties with an HTTP connection such that I can use > snippets, comet, etc. And I want those associations to be secure, more > or less. So I thought that I could base my app's security model on the > user getting IMed a URL > likehttp://my.app/?JSESSIONID=sdiofcxm,vnweioprhsdfjk, going to that URL and > changing their settings. If they don't visit that URL for half an hour > or so, the session dies and it becomes invalid, so someone can't use > browser history on a shared computer to access another's settings. > Similarly, getting IMed a new URL invalidates the old, so the user has > at least two ways of locking out others when using shared computers.
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: http://my.app;JSESSIONID=sdiofcxm?{params here} LiftSession has by default an inactivity period of 30 minutes. However you can configure the sessions expiration interval from /WEB-INF/ web.xml > > > LiftSession.scala manages sessions in Lift. > > Yeah, I've looked at that, but I just wasn't clear on whether or not > what I was trying was remotely possible. I recognize that it's kind of > an edge case, so I thought that those with more knowledge could at least > point me in the right direction--or, at least, in a direction more > substantial than LiftSession.scala. :) Sorry about that. You can use LiftRules.dispatch allows you to "register" your own function that will be called "staefuly" in a context of a HTTP session if you want to process HTTP based API's. Rrgarding your initial 3 points: 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. /*marius - It does by default. A request without a sessionid will create a HTTP session*/ 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. /*marius - If you need to know the list of active Lift sessions you can use SessionMaster.sessionWatchers. Lift would send your actor a SessionWatcherInfo message containing a Map[String, LiftSession] You can put properties on a session most recommendable using Lift's SessionVar. */ 3. Visiting a URL with a jsessionid parameter should whipe out any sessions set in cookies. /*marius - I'm not sure I understand this one.*/ 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. > > I hate to re-invent the wheel if I don't have to, and the access token > stuff I did in Ruby seems very much like externally referenced HTTP > sessions. -- 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.
