Session expiration question

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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" <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

You ought to be able to sort something out where you keep the session
around for plenty of time, store the last access time, and simply use
a decoration on the root component to prompt for authentication again
if a certain time has elapsed. This used to work perfectly, but in
2.9/3.0 this would now allow callbacks to still work, which you might
or might not want.

This is a shame really (it's biting me a different way in the Pier
port I'm working on) but was a design tradeoff we made... I wonder if
there's a more obvious solution now that all the other changes are
done...

You could also add a request filter to the session which blocks access
after a timeout. This is what I would generally recommend in terms of
security, but you're outside the render loop machinery when you block
the request so it's a bit harder to figure out how you're going to
deal with notification of the logout and accepting new credentials
(unless you're using HTTP Basic auth).

Obviously in either case you have to decide what you're actually going
to do with the data that was submitted in the request that was
blocked. That's going to be an application-specific decision I think.

Hope that's a little helpful.

Julian

On Fri, Sep 25, 2009 at 4:19 PM, Schwab,Wilhelm K <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside