From rtr at softelsystems.com.au Mon Jun 4 23:33:46 2007 From: rtr at softelsystems.com.au (Tyler Retzlaff) Date: Mon, 4 Jun 2007 23:33:46 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. Message-ID: Good day, 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. Thanks Tyler From andrewm at object-craft.com.au Tue Jun 5 00:12:24 2007 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 05 Jun 2007 00:12:24 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. In-Reply-To: References: Message-ID: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> >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). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From gregh at object-craft.com.au Thu Jun 14 10:12:56 2007 From: gregh at object-craft.com.au (Greg Hamilton) Date: Thu, 14 Jun 2007 10:12:56 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. In-Reply-To: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> References: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> Message-ID: <20070614001256.GO1135@object-craft.com.au> 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 From rtr at softelsystems.com.au Mon Jun 25 14:02:44 2007 From: rtr at softelsystems.com.au (Tyler Retzlaff) Date: Mon, 25 Jun 2007 14:02:44 +1000 Subject: [albatross-users] SessionAppContext handling session timeout / deleting. In-Reply-To: <20070614001256.GO1135@object-craft.com.au> References: <20070604141224.4AF785CC9D7@longblack.object-craft.com.au> <20070614001256.GO1135@object-craft.com.au> Message-ID: <97F9F5A3-32A5-4D76-9DD1-764E53192482@softelsystems.com.au> Ah yes I surface again. Sorry for the delayed response I have a lot on my plate these days. This is exactly what I am observing and barring any better solution.. Andrew? I'l do what you suggest. Thanks On 14/06/2007, at 10:12 AM, Greg Hamilton 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 >