On Jan 24, 9:29 pm, Nolan Darilek <[email protected]> wrote:
> 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?
In Jetty 6 put in your WEB-INF/jetty-web.xml
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Get name="sessionHandler">
<Get name="sessionManager">
<Set name="usingCookies" type="boolean">false</Set>
</Get>
</Get>
</Configure>
>
> > 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?
Not really. An HTTP session is always created by Lift when processing
stateful requests. But this not affect you. You could *mark* xmpp
session (or sessions that you're interested in ) with some SessionVar
or set some session property that you could set. But again a HTTP
session is not necessarily bound to an account.
> 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.
When this XMPP request is sent you can create some state into a
SessionVar. Otherwise the HTTP session will simply be an HTTP session
inside the container (and SessionMaster) ... and there is no harm in
that.
>
>
>
> > 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?
Yes, for SessionVar's yes but you'd need to be in the right context.
For instance:
1. If you're inside a Comet actor you just use SessionVar
2. If you're somewhere outside the request lifecycle you'd need to do
something like:
S.initIfUninitted(session) {
/// do your stuff here
}
but you'd need to obtain the LiftSession reference somehow.
>
> 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
You shouldn't be creating sessions manually. Session are *created* by
container and when this happens LiftSessions are also created
automatically.
> 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?
or SessionMaster.getSession(message.getFrom, Empty) this will give you
the session by a known ID.
>
> 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.
You cannot as LiftSessions are bound to the container's HTTP session.
>
> 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.
Based on your notes it looks to me that's cleaner if you just
designing you own session semantics especially if you absolutely need
to create sessions from the server side without involving requests.
But it's your call.
--
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.
