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
