[albatross-users] SessionAppContext handling session timeout / deleting.

[Tyler Retzlaff]

Hello,

I'm revisiting this again.  I've decided now that for the  
SessionExpired exception
I would like to:

1. remove the clients stale cookie (how?)
2. redirect to or respond with the login page.

Do I still need to override handle_exception() to achieve this?  Or  
is there a more
canonical way?  Having to override the handle_exception() method of  
the app
seems a bit overblown since I'm reasonably happy with what it already  
does by
default.  It seems that I could just instantiate a new app context  
with the request
object in __main__ and redirect() or is that not sensible/won't work?


Thanks


On 25/06/2007, at 2:02 PM, Tyler Retzlaff wrote:

>
>> On Tue, Jun 05, 2007 at 12:12:24AM +1000, Andrew McNamara wrote:
>>   | >I'm using SessionAppContext/SimpleSessionApp for server side   
>> sessions.
>>   | >After a server session times out and I receive a subsequent  
>> request from a
>>   | >client  (which had a session) as a result a SessionExpired  
>> exception is
>>   | >raised (quite correctly  since it timed out) which I guess I  
>> have to catch
>>   | >at app.run(Request()).
>>   | >
>>   | >What is the right way to delete the old session and return a  
>> selected
>>   | >template page?  I notice your FAQ has an entry describing how  
>> to delete a
>>   | >session  when I have a handle to the context.  But in this  
>> case I don't
>>   | >have a handle to the  context because of where I am handling  
>> the exception
>>   | >and presumably because if it is  expired it never got  
>> instantiated for
>>   | >that request...
>>   | >
>>   | >Feel free to point me to relevant documentation (I did look  
>> but  nothing
>>   | >jumped out at me that seemed appropriate) but I am new to  
>> Albatross and
>>   | >may have  missed it.
>>   |
>>   | Hmmm, tricky. There's no need to delete the session, since  
>> it's already
>>   | gone: I suspect what you should do is replace the default  
>> exception page
>>   | with a friendlier version for this specific exception.
>>   |
>>   | The Application classes call their handle_exception() method  
>> when the run
>>   | method raises an exception - you could subclass the  
>> Application class
>>   | you've chosen, and add your own handle_exception method that  
>> presents
>>   | your chosen template.
>>   |
>>   | Have a look at Application.handle_exception() in albatross/ 
>> app.py -
>>   | you'll basically want to do something very similar to what's  
>> there.
>>   |
>>   | If you think overloading the albatross method is against the  
>> rules,
>>   | don't worry - this is the way Albatross is intended to be used  
>> (which
>>   | is why all manner of "internal" methods are documented).
>>   |
>>
>> I've been bitten by this before. The default handle_exception removes
>> the session for any unhandled exception. The browser still has a  
>> cookie
>> identifying the removed session. All subsequent requests result in a
>> SessionExpired exception.
>>
>> I work around this by removing the session and creating a new session
>> before I run the template which reports the error.
>>
>> Something like this ...
>>
>>     def handle_exception(self, ctx, req):
>>         ctx.remove_session()
>>         ctx.new_session()
>>         ctx.reset_content()
>>         self.save_session(ctx)
>>         ctx.run_template('unhandled_exception.html')
>>         ctx.flush_content()
>>
>> I'm sure Andrew will be appalled by this and suggest a far superior
>> solution.
>>
>> Greg Hamilton
>> Object Craft
>>
>
> _______________________________________________
> Albatross-users mailing list
> Albatross-users at object-craft.com.au
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross- 
> users
>