authorization by user or IP, 2nd try

[Stefan Fritsch <sf...@sfritsch.de>]

Hi,

in order to allow authorization by user _or_ IP using a <RequireAny> 
block, r956387 tries to continue with authorization (the auth_checker 
hook) even if authentication (the check_user_id hook) failed.  This 
has two problems:

- If authorization succeeds because of IP, one would need to undo the 
effects of note_*_auth_failure, which has been called by the failed 
authentication function.  In the case of basic auth, this means 
removing the WWW-Authenticate header, but for more complex auth types, 
this can be more complex.

- With more complex auth types, creating the WWW-Authenticate header 
can involve expensive crypto operations. This is a waste if we allow 
the access without authentication anyway.

Therefore I had the idea to introduce a new hook between the 
access_checker and the check_user_id hooks. Differently from 
access_checker, this would be a RUN_FIRST hook and a result of OK 
would mean 'immediately grant access'. DECLINED would mean 'go on with 
authentication' and other values would mean denied.  mod_authz_core 
could then use this hook to grant or deny access if the result of 
authorization does not depend on the user name. In order to know
that, any authz provider that does authorization by user would have to 
return a special return code AUTHZ_DENIED_NO_USER if r->user == NULL. 
(Or there could be a flag in the authz_provider struct).

I have an (incomplete) patch at
http://people.apache.org/~sf/access_checker_authoritative.diff

Does this make sense?  If yes, what would be a good name for the new 
hook? access_checker_authoritative, access_checker_ex, 
auth_checker_userless, ...?

mod_access_compat could also use the new hook to implement Satisfy 
all/any without having the logic in the core. Would it make sense to 
remove the ap_satisfies() API from the core? I believe not. For 
example mod_ssl still uses the access_checker hook and is therefore 
influenced by satisfy all/any.

Cheers,
Stefan


PS: I don't think we have enough automated tests for all the new 
auth/authz/authn modules. If anybody cares about a particular module 
and has some time, please write tests.