From rtr at softelsystems.com.au Wed Sep 12 17:58:32 2007 From: rtr at softelsystems.com.au (Tyler Retzlaff) Date: Wed, 12 Sep 2007 17:58:32 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. In-Reply-To: <97F9F5A3-32A5-4D76-9DD1-764E53192482@softelsystems.com.au> References: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> <20070614001256.GO1135@object-craft.com.au> <97F9F5A3-32A5-4D76-9DD1-764E53192482@softelsystems.com.au> Message-ID: 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 > From andrewm at object-craft.com.au Thu Sep 13 09:16:07 2007 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 13 Sep 2007 09:16:07 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. In-Reply-To: References: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> <20070614001256.GO1135@object-craft.com.au> <97F9F5A3-32A5-4D76-9DD1-764E53192482@softelsystems.com.au> Message-ID: <20070912231607.AA73978C116@longblack.object-craft.com.au> >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. You could try setting the stale cookie's expiry time to "1970-1-1 00:00:01" (or any time in the past, really, but the unix "epoch" is probably the safest). You'll probably also need to send a fresh cookie at the same time. >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? Your other alternative is to wrap the load_session method. You could call the base load_session, and if that raises SessionExpired, then catch it, and call new_session() (the app should go to the start (login) page by itself in this case). Don't be worried about overloading Albatross methods - this is the way it's meant to work. Rather than provide you with an all singing, all dancing API that is hard to learn and still never quite does what you want, Albatross provides you with some basic building blocks and lets you assemble them however you want. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/