[Seaside] Session expiration question

[Julian Fitzell]

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