[Seaside] Session expiration question

[Davorin Rusevljan]

Bill,

I am preparing to write an app with a very long form, and I am concerned
about the same problem. My current plan is to use ajax to send an update for
each field entered (and store it in db). This does increase load on the
server, but as long as each field is not long, it keeps amount of work that
can be lost reasonably small.

But if you have large text fields where user is supposed to enter several
pareagraphs then maybe something like gmail which autosaves message text
after some time passes might be the way.

Lastly maybe you could deal with expiry problem by acting before it happens.
Something like innactivity timer in browser which jumps to special
"inactivity page", which displays password reentry dialog, and until user
enters pass it sends in backgropund ajax session keep alive packets. When
user submits the password, you transfer control back to the calling page. If
he closes window, session eventually expires.

rush
http://www.cloud208.com/

On Sep 25, 2009 4:19 PM, "Schwab,Wilhelm K" <bschwab at anest.ufl.edu> wrote:

Hello all,

I am gradually gaining confidence with mixing Seaside and SSL.  The next
step is to ensure that only authenticated users can access the
application(s), which seems easy enough by simply demanding a password in
the first component.  I have some more work to do, such as allowing users to
change their password (unless I pawn that off to our directory system), and
ideally finding a nice way to persist (hashed of course) passwords either in
a database or other storage.  If any of you have particularly elegant
solutions to the latter, I'd be all ears :)

My current concern is over work a user might do in a session that expires.
 I would rather not have to answer with: "sorry, it's gone, you're screwed,
work faster next time," but that would be far better than security breaches,
and the application already allows the user to attack the work a few small
bites at a time.  Is there a robust way to drop the user into a task/loop
that re-authenticates and then allows work to continue where the user lefr
off?  If they close the browser, I have no sympathy; I'm thinking of
timeouts.

Bill

_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090925/c24f9b50/attachment-0001.htm