handling session timeout

[steve.yen]

I'm wondering how to handle this usage case in lift... Think of
composing an email in gmail/ymail.

1. Jerry starts a new email in some compose form.
2. Before finishing, Jerry goes away for a coffee run.
3. Meanwhile, the session has timed out or the server restarted.
4. Jerry's back, finishes typing in his email and hits Submit

What's irritating is if the app loses all of Jerry's work, which is
what happens when I use the following kind of emailComposeForm snippet
code, where Email is a mapped model object.

object formCurrent extends RequestVar[Email](Empty)

def emailComposeForm: NodeSeq = {
formCurrent.openOr(new Email).toForm(
Full("Create a new email"),
(x: Email) => {
x.validate match {
case Nil => x.save; S.redirectTo(urlShow(x))
case xs => S.error(xs); formCurrent(x)
}
}
)
}

What's happening is all the closures got blown away at step 3, so a
brand new empty compose form is returned after step 4. However, all
the Jerry's effort and work did get POST'ed up to the server, albeit
scrambled up with (secure? (*)) randomized parameter names.

I would like to be able to do something nicer. Just saving the email
with no fuss for Jerry is one thought. Perhaps show the same compose
form with all of Jerry's work pre-entered, but with a "Your session
has timed out. Please try again" message (I see Google Groups seems
to do this).

Using lift's S.ajax features won't work, because of the same closure
loss and randomized input param name issue.

Perhaps a way to tell lift to not generate randomized input param
names is part of the answer? For example handwave, saying...
formCurrent.openOr((new
Email).populateFromParams).toLessSecureForm(...)
instead of...
formCurrent.openOr(new Email).toForm(...)

Or, other ideas?

(*) - Aside: does the input param name randomization help a lot? I
can think of this: it prevents kiddies from copy-&-pasting direct view-
source HTML forms for nefarious purposes. But, it (or any other
system) can't prevent any evil client code that bothers to pretend to
be an end user browser.

Thanks,
Steve

[David Bernard]

An other solution, I used it (with Wicket) for same purpose : using a ajax code that call the server and keep the session alive.
Do a try by adding the Clock sample into your page, then you could use this feature to auto-save draft version.

WDYT ?

[Viktor Klang]

On Jan 9, 2008 10:58 PM, David Bernard <david.be...@gmail.com> wrote:

An other solution, I used it (with Wicket) for same purpose : using a ajax code that call the server and keep the session alive.
Do a try by adding the Clock sample into your page, then you could use this feature to auto-save draft version.

WDYT ?

Suggesting creating of something as easy as: LiftServlet.keepalive()

-V

 

>         formCurrent.openOr (new Email).toForm(...)

>
> Or, other ideas?
>
> (*) - Aside: does the input param name randomization help a lot?  I
> can think of this: it prevents kiddies from copy-&-pasting direct view-
> source HTML forms for nefarious purposes.  But, it (or any other
> system) can't prevent any evil client code that bothers to pretend to
> be an end user browser.
>
> Thanks,
> Steve
>
> >

--
_____________________________________
/                                                                 \
       /lift/ committer (www.liftweb.net)
     SGS member (Scala Group Sweden)
 SEJUG member (Swedish Java User Group)
\_____________________________________/

[David Pollak]

Yeah... there's gotta be a way to persist "meaningful" pages...
serialize the forms, send them to the server and if the session times
out (someone closes their laptop), once they reauthenticate, they get
their world back the way it was.

Interesting problem... and probably post 1.0.

[John D. Heintz]

This is where the "stateful" aspect of lift is at odds with the
"stateless" constraint of REST [1].

It seems to me the only options are:
1) Push more data into the form and out of the server-state closures
(and hurt the security lift enables).
2) Have per user stores that durably survive sessions (and hurt
performance/scalability)

The closures on the server-side enable three features (right?):
* security
* efficient async (comet) interactions
* and long running stateful sequences (wizards)

DavidP, can you explain the security benefits in a little more? In the
case of a simple form (not comet and not a wizard) how much benefit in
terms of a secure system does this provide?

Thanks,
John

[1] See http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1
"communication must be stateless in nature..., such that each request
from client to server must contain all of the information necessary to
understand the request, and cannot take advantage of any stored
context on the server. Session state is therefore kept entirely on the
client."

--
John D. Heintz
Principal Consultant
New Aspects of Software
http://newaspects.com
http://johnheintz.blogspot.com
Austin, TX
(512) 633-1198

[steve.yen]

Interesting idea on the ajax auto-save, which seems helpful with the
case of session timeout. But, on a server bounce case... still no
love.

Another idea, related to what JohnH said about security...

> It seems to me the only options are:
> 1) Push more data into the form and out of the server-state closures
> (and hurt the security lift enables).

We might not have to change or add very much data at all. Currently,
lift generates output such as...

Subject:
<input value="" type="text"
name="F207776643183980_WDR" />

Instead, if lift (optionally?) generated something like...

Subject:
<input value="" type="text"
name="subject_F207776643183980_WDR" />

Then we would have enough info to reconstruct and rescue the user's
input, and also still prevent Cross-Site-Whatchamacallit attacks?

cheers,
steve

[David Pollak]

Steve,

steve.yen wrote:

Interesting idea on the ajax auto-save, which seems helpful with the
case of session timeout.  But, on a server bounce case... still no
love.
  

It's still love because the client state would be persisted in some ACID place (database, etc.) with plenty of metadata to reconstruct the form without the need for "subject_xxxx"

[David Pollak]

John,

You are assuming the REST is good.  REST is bad for human interactions.  Humans are not stateless.  Applications should reflect this.

lift has great capabilities for doing machine to machine REST.

All the form generation stuff in lift will run screaming away from REST and statelessness.  lift is not a tool for building green screen applications that are thin layers on top of the database schema.

lift's binding of form generation and form submission (e.g., text(startingvalue, v => thing to do with the value) ) is well typed.  You don't have to remember that the name of the form element is "foo".  It treats what is on the browser as a part of your program with opaque identifiers that bind back to the action to be taken.  It abstracts away the HTTP/HTML request response cycle.

Thanks,

David