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 like
http://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.
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. :)
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
