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 </Files> or: AuthType Session AuthName "Private Area" Require valid-user PythonAuthenHandler _sessionmanager <Files login.html> AuthName "Public Area" </Files> 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 correct. Graham
