Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12369766 ]
Graham Dumpleton commented on MODPYTHON-124:
--------------------------------------------
req.ap_auth_type is called what it is and is a member as that is what it is called in the
request_rec struture. I didn't prepend it with "ap_". See:
http://docx.webperf.org/structrequest__rec.html
I agree that it looks strange, but I kept the convention of preserving the
names as they appear in the request_rec structure. It is the only member in
request_rec that has such a prefix.
req.auth_type() and req.auth_name() are functions as that reflects the fact
that they are actually functions in the Apache API. See:
http://httpd.apache.org/dev/apidoc/apidoc_ap_auth_type.html
http://httpd.apache.org/dev/apidoc/apidoc_ap_auth_name.html
Again, thus followed convention as I saw it reflected in implementation of
requestobject. Ie., for a function drop the 'ap_' prefix.
Note that req.ap_auth_type and req.auth_type() are not the same thing.
The req.auth_type() function returns the value associated with the AuthType
directive.
The req.ap_auth_type member of the request_rec initially starts out as None.
One of the things that an authentication handler will do if it handles the
authentication type returned by req.auth_type() is to set req.ap_auth_type to
be not None. Presumably it would be set to same value as returned by
req.auth_type() at that point. It would also set req.user.
Thus, the req.ap_auth_type being non None is an indicator that an
authentication module has processed the authentication for the request and also
indicates who it was.
That the req.ap_auth_type member kept the 'ap_' prefix by convention was a blessing, else
there would have been a clash on the use of the "auth_type" name and one would
have had to break the convention that seems to exist for this one case.
OK, I get it now. We'll need the documentation to be more explicit. I'll
update the docs and you can let me know if I get it right. :)
Jim
