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:

http://my.app;JSESSIONID=sdiofcxm?{params here}

That'd be perfect, and is one aspect of the whole user token thing. Is it possible to disable this on an app-by-app basis? Can I put something in Boot.scala or web.xml to disable cookie-based sessions just for this app?


LiftSession has by default an inactivity period of 30 minutes. However
you can configure the sessions expiration interval from /WEB-INF/
web.xml

And again, this is perfect. This is why I'm trying to (ab)use sessions in this manner, they already encapsulate most of the behaviors I need, and the less code I have to write myself, the better.

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*/

Right, I get this. So my question is, can I stipulate that visitors to /index.html *don't* generate a session? The default index page is just a blurb about the service. To create an account, the user has to poke it via XMPP, and if the user doesn't do this then there's no sense creating a session for them.

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.

  */

And I can set and access these properties from outside of snippets or the HTTP lifecycle?

Here's pseudocode that may help illustrate some of what I'm trying to accomplish. Note that I'm totally making up Lift APIs here just to get the concepts across. This would be code that matches incoming XMPP messages to commands, so this is not running in the web app itself:

message.getBody match {
  ...
  case "config" =>
val old = SessionPool.find("owner", message.getFrom) // Does user have a session already? if(old != None) old.get.destroy // User requests new session so invalidate old to prevent hijack.
    val session = session.new
    session.setSessionVar("owner", new SessionVar(message.getFrom))
message.reply("Please visit ",session.getURL," to configure your account.")
  ...
}

I'm studying LiftSession.scala and see SessionMaster.getSession. Can I set otherId to the JID of the session's owner? So I could replace SessionPool.find in the above code with:

SessionMaster.getSession("", Some(message.getFrom))

or am I misunderstanding?

I'm also not clear on how to create a blank session so I have a URL to hand back to the user. I know that this is normally done by the incoming HTTP request, but in this instance I want the XMPP command to prepare a fresh session for the user to visit.

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.*/

Well, if I can disable cookie-based sessions in this app then it's a non-issue.

Thanks for all the help so far.

--
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.

Reply via email to