Jim Gallacher (JIRA) wrote .. > I think part of the problem with process_auth() is the uncertainty of meaning > associated with auth and __auth__. Does it mean authenticate or authorize? > If it's authorize, then there is no reason to call __auth__ with the password. > Likewise, you shouldn't need the user name when calling __access__. One > could certainly come up with access rules which are not tied to a specific > user. > > Maybe we should consider refactoring process_auth() to look for 2 new > attributes > such as __authen__ and __author__, and deprecate the use of __auth__. If > somebody wants to do authentication in publisher then their code would > be completely responsible for returning either a user or raising an error. > (Further discussion of this should be shifted out of this particular issue).
Yes __auth__ is effectively equivalent to authenhandler, but __access__ is actually equivalent to authzhandler and not accesshandler as it suggests. In other words I see __access__ to be there to allow doing the equivalent of the "Require" directive where a user name would actually be required. Given the fragility of __auth__/__access__ functions nested inside of a function, I would suggest just leave it as is and perhaps steer people to using an actual acesshandler/authhandler/authzhandler instead. That is, promote the Apache way of doing things. This doesn't even mean that these steps need be done in Python as mod_auth or other authentication and authorisation modules written in other languages could just as easily be used. I'll have a lot more to say about this at a future date when I have finished some examples I am writing of authentication/authorisation handlers in mod_python implemented in the proper Apache way. This wasn't actually possible to do until I committed some of the changes I did in 3.3 trunk. Graham