|
As usual there is nearly always a way to fudge things. You could still use Apache HTTP digest authentication (managed by Apache) and still use mod_python.publisher by having an authenhandler() or earlier content handler which deleted the "Authorization" header so that mod_python.publisher didn't find it and therefore didn't barf.
def authenhandler(req): if req.headers_in.has_key("Authorization"): del req.headers_in["Authorization"] ... etc. I haven't tried this, but it should work. The simplest way of fixing this problem may be that after changes related to
In other words, if AuthType directive has been defined assume that something else is handling authentication and that publisher doesn't have to worry about it. This will mean publisher will not redundantly decode authorisation header if AuthType was Basic and was being handled explicitly by mod_auth in Apache and outside of the publisher. Thus, insert at start of process_auth(): if req.ap_auth_type: return realm, user, passwd Attached "MP47_20060307_grahamd_1.diff" with proposed patch. Feedback on this one appreciated.
I'm don't really like this patch (MP47_20060307_grahamd_1.diff) as it bypasses any authorization or access checks in the object being published.
Authentication != authorization I'm not sure what the answer is, but I think we all know that the problem lies in the fact that publisher is too tightly bound to basic authentication. Attached alternate suggested fix as "MP47_20060309_grahamd_2.diff".
I should have just done it this way to begin with. What this does is simply not try and do anything with the Authorization header unless either __auth__ or __access_ are actually found. Ie., the fix I originally described, rather than my latter obsession with req.ap_auth_type. This means that if one has __auth__ or __access__ and Apache configuration still uses digest authentication it will fail. But if one knows one is using digest authentication support in mod_auth, you would not be using the publisher auth support anyway as they would conflict. I agree that authentication should not be part of publisher, but can't do anything about that now. Apache has a really good concept of phases yet just about everything merely uses mod_python as a hopping off point at content handler phase and does everything in that one phase. :-( The second patch is likely the best compromise.
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). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
Digest Authorization header causes bad request error.
post at the time with suggested fix was:
http://www.modpython.org/pipermail/mod_python/2002-September/013071.html
The suggested fix at the time was to set user,passwd to None,None with similar
check as initially suggested this time round.
In vampire::publisher where similar problem existed, was found to be better to
defer parsing of Authorization until determined it was needed though as it then
mean't you got a hard error if actually trying to use __auth__ or __access__ instead
of it being silently ignored. Ie., error would occur still where you were trying to
mix two different authorisation types.