Skip to content
  1. Oct 29, 2008
  2. Oct 28, 2008
  3. Oct 27, 2008
  4. Oct 26, 2008
  5. Oct 25, 2008
  6. Oct 24, 2008
  7. Oct 23, 2008
  8. Oct 22, 2008
  9. Oct 21, 2008
  10. Oct 20, 2008
  11. Oct 19, 2008
  12. Oct 17, 2008
  13. Oct 16, 2008
    • Chris Darroch's avatar
      Prior to authn/z refactoring in r368027, if authorization Require · 65d1ef00
      Chris Darroch authored
      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.
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@705361 13f79535-47bb-0310-9956-ffa450edef68
      65d1ef00