Jim Gallacher wrote ..
> 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?

In the case where a session is required across both public and private
areas of a web site where login is required for the private area, the
example I am working on handles that.

I am still working out what presents as being the more sensible way, but
Apache configuration would be something like:

  AuthType Session::Private
  Require valid-user
  PythonAuthenHandler _sessionmanager

  <Files login.html>
  AuthType Session::Public


  AuthType Session
  AuthName "Private Area"
  Require valid-user
  PythonAuthenHandler _sessionmanager

  <Files login.html>
  AuthName "Public Area"

The benefit of using an authenhandler in this case is that it doesn't
particularly matter what is being used for the content handler phase as
longs as access to resources can be controlled based on filename matched
by Apache for the URL, or possibly by the URL itself. Thus, you could be
using publisher or PSP, or even a mix. Whatever is used, it just uses the
req.session object created for it by the authenhandler.

Sure the code might not handle every single possible use case, but its
purpose was an example, not something to be embodied into any package.
Thus, it could by all means be customised. The important thing is
illustrates how to do all the hard stuff that people don't generally get


Reply via email to