follow-up to r1554161, r1554168, r1554170, r1554175, r1554188, and r1554195: axe unnecessary initialization/pool allocation

Pass the correct pointer that made it past the test suite.

mod_authnz_dbd: Support the expression parser within the require directives.

cppCheck: Suspicious condition. AFAIK, there is no actual problem with the existing code. 'rv' would only not have the 'expected' value, but the execution path would remain the same. However, the patched code is more logical. We put the returned value in 'rv', then test it against 0.

Correctly log the error returned by apr_dbd_pvselect()

Add lots of unique tags to error log messages

Cleanup effort in prep for GA push: Trim trailing whitespace... no func change

Forbid some directives in .htaccess because of AllowOverrideList: core: AllowOverride, AllowOverrideList mod_authn_dbd: AuthDBDUserPWQuery, AuthDBDUserRealmQuery mod_authz_dbd: AuthzDBDQuery, AuthzDBDRedirectQuery mod_proxy: BalancerMember, ProxySet Adjust for use in .htaccess: mod_actions: Script

Allow authz providers to check args while reading the config and allow them to cache parsed args. Use this to check that argument to 'all' provider is 'granted' or 'denied'.

The approach for allowing authorization by user or IP introduced in r956387, etc. causes problems because the authentication module calls note_*_auth_failure if authentication fails. This is inappropriate if access is later allowed because of the IP. So, instead of calling the auth_checker hook even if authentication failed, we introduce a new access_checker_ex hook that runs between the access_checker and the check_user_id hooks. If an access_checker_ex functions returns OK, the request will be allowed without authentication. To make use of this, change mod_authz_core to walk the require blocks in the access_checker_ex phase and deny/allow the request if the authz result does not depend on an authenticated user. To distinguish a real AUTHZ_DENIED from an authz provider from an authz provider needing an authenticated user, the latter must return the new AUTHZ_DENIED_NO_USER code.

Use the new APLOG_USE_MODULE/AP_DECLARE_MODULE macros everywhere to take advantage of per-module loglevels

Prior to authn/z refactoring in r368027, if authorization Require directives had no matching AuthType and associated authentication directives, requests would generally fall through in the check_user_id hook to mod_authn_default.c's authentication_no_user() handler, which returned DECLINED if ap_auth_type() was not set. The ap_process_request_internal() function in request.c would handle this case by logging an "AuthType not set!" error and returning HTTP_INTERNAL_SERVER_ERROR. The refactoring removes this error handling in request.c, so individual modules will need to test for a lack of authentication, as necessary. Since some modules such as mod_authz_host.c support Require directives that do not need any authentication, the mod_authn_default.c handler no longer returns DECLINED if ap_auth_type() is not set. (Also, mod_authn_default can be compiled out with --disable-authn-default, so it can't be relied upon to exist.) Since r->user may now be NULL, individual handlers must test for that case when necessary. Otherwise, most Require directives in the absence of AuthType directives cause handlers to crash while performing strcmp() and friends on a NULL r->user value. NOTE: I can't test mod_authnz_ldap.c myself, so I'm not sure if it needs similar fixes. On the one hand, a NULL r->user in the authz handlers always generates a log message. However, it appears that authn_ldap_build_filter() will sometimes then be called, perform no action, which may result in a possibly uninitialized filtbuf buffer being passed to util_ldap_cache_getuserdn(). I don't know if that could cause problems in the LDAP cache code. If someone familiar with LDAP authz could take a look, that would be much appreciated.

Convert common provider version strings ("0") to AUTHN/Z_PROVIDER_VERSION macros defined in mod_auth.h.

Avoid calling access control hooks for internal requests with configurations which match those of the initial request. Revert to the original behaviour (call access control hooks for internal requests with URIs different from the initial request) if any access control hooks or providers are not registered as permitting this optimization. Introduce wrappers for access control hook and provider registration which can accept additional mode and flag data. The configuration walk optimizations were originally proposed a while ago (see http://marc.info/?l=apache-httpd-dev&m=116536713506234&w=2); they have been used since then in production systems and appear to be stable and effective. They permit certain combinations of modules and clients to function efficiently, especially when a deeply recursive series of internal requests, such as those generated by certain WebDAV requests, are all subject to the identical authentication and authorization directives. The major change from the original proposal is a cleaner mechanism for detecting modules which may expect the old behaviour. This has been tested successfully with Subversion's mod_authz_svn, which specifically requires the old behaviour when performing path-based authorization based against its own private access control configuration files.

Return AUTHZ_GRANTED not AUTHZ_DENIED when redirecting after successful login/logout. Use redirection URL from first row returned by DB query, in the same manner as that used by mod_authn_dbd when querying for a single record.

You can't borrow AP_ namespace for imports/exports. They are specific to one loadable module.

update license header text

Authz refactoring Merge from branches/authz-dev Basically here is a list of what has been done: - Convert all of the authz modules from hook based to provider based - Remove the ap_requires field from the core_dir_config structure - Remove the function ap_requires() since its functionality is no longer supported or necessary in the refactoring - Remove the calls to ap_some_auth_required() in the core request handling to allow the hooks to be called in all cases. - Add the new module mod_authz_core which will act as the authorization provider vector and contain common authz directives such as 'Require', 'Reject' and '<RequireAlias>' - Add the new module mod_authn_core which will contain common authentication directives such as 'AuthType', 'AuthName' and '<AuthnProviderAlias>' - Move the check for METHOD_MASK out of the authz providers and into the authz_core provider vector - Define the status codes that can be returned by the authz providers as AUTHZ_DENIED, AUTHZ_GRANTED and AUTHZ_GENERAL_ERROR - Remove the 'Satisfy' directive - Implement the '<RequireAll>', '<RequireOne>' block directives to handle the 'and' and 'or' logic for authorization. - Remove the 'AuthzXXXAuthoritative' directives from all of the authz providers - Implement the 'Reject' directive that will deny authorization if the argument is true - Fold the 'Reject' directive into the '<RequireAll>', '<RequireOne>' logic - Reimplement the host based authorization functionality provided by 'allow', 'deny' and 'order' as authz providers - Remove the 'allow', 'deny' and 'order' directives - Merge mod_authn_alias into mod_authn_core - Add '<RequireAlias>' functionality which is similar to '<AuthnProviderAlias>' but specific to authorization aliasing - Remove all of the references to the 'authzxxxAuthoritative' directives from the documentation - Remove the 'Satisfy' directive from the documentation - Remove 'Allow', 'Deny', 'Order' directives from the documentation - Document '<RequireAll>', '<RequireOne>', 'Reject' directives - Reimplement the APIs ap_auth_type(), ap_auth_name() as optional functions and move the actual implementation into mod_authn_core - Reimplement the API ap_some_auth_required() as an optional function and move the actual implementation into mod_authz_core Major Changes: - Added the directives <RequireAll>, <RequireOne>, <RequireAlias>, Reject - Expanded the functionality of the directive 'Require' to handle all authorization and access control - Added the new authz providers 'env', 'ip', 'host', 'all' to handle host-based access control - Removed the directives 'Allow', 'Deny', 'Order', 'Satisfy', 'AuthzXXXAuthoritative' - Removed the ap_require() API - Moved the directives 'AuthType', 'AuthName' out of mod_core and into mod_authn_core - Moved the directive 'Require' out of mod_core and into mod_authz_core - Merged mod_authn_alias into mod_authn_core - Renamed mod_authz_dbm authz providers from 'group' and 'file-group' to 'dbm-group' and 'dbm-file-group' Benefits: - All authorization and access control is now handle through two directives, 'Require' and 'Reject' - Authorization has been expanded to allow for complex 'AND/OR' control logic through the directives '<RequireAll>' and '<RequireOne>' - Configuration is now much simpler and consistent across the board - Other modules like mod_ssl and mod_proxy should be able to plug into and take advantage of the same provider based authorization mechanism by implementing their own providers Issues: - Backwards compatibility between 2.2 and 2.3 configurations will be broken in the area of authorization and access control due to the fact that the directives 'allow', 'deny', 'order' and 'satisfy' have been removed. When moving from 2.2 to 2.3 these directives will have to be changed to 'Require all granted', 'Require all denied' or some variation of the authz host-based providers. - Existing third party authorization modules will have to adapt to the new structure.

mod_authz_dbd: SQL authz with Login/Session support