quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: get_session(), req.session, req.form and MODPYTHON-38
Date Tue, 14 Mar 2006 01:34:18 GMT
Graham Dumpleton wrote:
> Jim Gallacher wrote ..
> 
>>The idea of something like req.get_session() is to give users an obvious
>>way to grab a session object without the deadlock concerns. How many 
>>times have we seen this kind of problem-code on the mailing list?
>>
>>def index(req):
>>     sess = Session.Session(req)
>>     do_stuff(req)
>>     ...
>>
>>def do_stuff(req):
>>     sess = Session.Session(req)
>>     ... do other stuff.
>>
>>Having the session constructor check for the existence of req.session is
>>of no use here. We need a way to make sure only *one* session instance
>>is created per request. (Bonus marks for making it work with internal 
>>redirect).
> 
> 
> FWIW, I use the following in a class based authenhandler.
>         
>         thread = threading.currentThread()
>         
>         if self.__cache.has_key(thread):
>             req.session = self.__cache[thread]
>         else:
>             req.session = Session.Session(req)
>         
>             self.__cache[thread] = req.session
>             def cleanup(data): del self.__cache[thread]
>             req.register_cleanup(cleanup)
> 
> In short, store it in a cache outside of the request object keys by
> the thread ID.
> 
> Works for both internal redirects and also for fast redirects as used by
> DirectoryIndex matching algorithm, although for the latter there are
> other issues as I have documented in MODPYTHON-146.
> 
> My thinking keeps changing a bit, but overall I have been leaning
> towards not having a get_session() like function explicitly provided and
> instead documenting how to correctly write a authenhandler which can
> handle form based login with sessions. Ie., use Apache phases properly
> rather than pushing authentication into content handler phase as most
> do. 

Which is all good, but you are assuming that people are only using 
sessions for authentication purposes. Consider a shopping cart 
implemented as  session: the user may not be authenticated until *after* 
they have filled their cart and are ready to checkout. Perhaps the cache 
code would be better off in Session.py?

Jim




Mime
View raw message