Apache2::Access - A Perl API for Apache request object: Access, Authentication and Authorization.

  use Apache2::Access ();

  # allow only GET method
  $r->allow_methods(1, qw(GET));

  # Apache Options value
  $options = $r->allow_options();

  # Apache AllowOverride value
  $allow_override = $r->allow_overrides();

  # auth name ("foo bar")
  $auth_name = $r->auth_name();

  # auth type
  $auth_type = $r->auth_type();
  $r->auth_type("Digest");

  # Basic authentication process
  my ($rc, $passwd) = $r->get_basic_auth_pw();

  # the login name of the remote user (RFC1413)
  $remote_logname = $r->get_remote_logname();

  # dynamically figure out which auth has failed
  $r->note_auth_failure();

  # note Basic auth failure
  $r->note_basic_auth_failure();

  # note Digest auth failure
  $r->note_digest_auth_failure();

  # Apache Request value(s)
  $requires = $r->requires();

  # Apache Satisfy value (as a number)
  $satisfy = $r->satisfies();

  # check whether some auth is configured
  $need_auth = $r->some_auth_required();

The API provided by this module deals with access, authentication and authorization phases.

CWApache2::Access extends CWApache2::RequestRec.

CWApache2::Access provides the following functions and/or methods: Specify which HTTP methods are allowed

  $r->allow_methods($reset);
  $r->allow_methods($reset, @methods);

ret: no return value

since: 2.0.00

For example: here is how to allow only CWGET and CWPOST methods, regardless to what was the previous setting:

  $r->allow_methods(1, qw(GET POST));

  $options = $r->allow_options();

since: 2.0.00

For example if the configuration for the current request was:

  Options None
  Options Indexes FollowSymLinks

The following applies:

  use Apache2::Const -compile => qw(:options);
  $r->allow_options & Apache2::Const::OPT_INDEXES;   # TRUE
  $r->allow_options & Apache2::Const::OPT_SYM_LINKS; # TRUE
  $r->allow_options & Apache2::Const::OPT_EXECCGI;   # FALSE

  $allow_override = $r->allow_overrides();

since: 2.0.00

For example if the configuration for the current request was:

  AllowOverride AuthConfig

The following applies:

  use Apache2::Const -compile => qw(:override);
  $r->allow_overrides & Apache2::Const::OR_AUTHCFG; # TRUE
  $r->allow_overrides & Apache2::Const::OR_LIMIT; # FALSE

  $auth_name = $r->auth_name();
  $auth_name = $r->auth_name($new_auth_name);

since: 2.0.00

The CWAuthName directive creates protection realm within the server document space. To quote RFC 1945 These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The client uses the root URL of the server to determine which authentication credentials to send with each HTTP request. These credentials are tagged with the name of the authentication realm that created them. Then during the authentication stage the server uses the current authentication realm, from CW$r->auth_name, to determine which set of credentials to authenticate. Get/set the type of authorization required for this request (the per directory configuration directive CWAuthType):

  $auth_type = $r->auth_type();
  $auth_type = $r->auth_type($new_auth_type);

since: 2.0.00

Normally CWAuthType would be set to CWBasic to use the basic authentication scheme defined in RFC 1945, Hypertext Transfer Protocol HTTP/1.0. However, you could set to something else and implement your own authentication scheme. Get the password from the request headers

  my ($rc, $passwd) = $r->get_basic_auth_pw();

since: 2.0.00

If CWAuthType is not set, this handler first sets it to CWBasic. Retrieve the login name of the remote user (RFC1413)

  $remote_logname = $r->get_remote_logname();

since: 2.0.00

Do not confuse this method with CW$r->user, which provides the username provided by the user during the server authentication. Setup the output headers so that the client knows how to authenticate itself the next time, if an authentication request failed. This function works for both basic and digest authentication

  $r->note_auth_failure();

ret: no return value

since: 2.0.00

This method requires CWAuthType to be set to CWBasic or CWDigest. Depending on the setting it'll call either CW$r->note_basic_auth_failure or CW$r->note_digest_auth_failure. Setup the output headers so that the client knows how to authenticate itself the next time, if an authentication request failed. This function works only for basic authentication

  $r->note_basic_auth_failure();

ret: no return value

since: 2.0.00

Setup the output headers so that the client knows how to authenticate itself the next time, if an authentication request failed. This function works only for digest authentication.

  $r->note_digest_auth_failure();

ret: no return value

since: 2.0.00

Retrieve information about all of the requires directives for this request

  $requires = $r->requires

since: 2.0.00

This is normally used for access control.

For example if the configuration had the following require directives:

    Require user  goo bar
    Require group bar tar

this method will return the following datastructure:

  [
    {
      'method_mask' => -1,
      'requirement' => 'user goo bar'
    },
    {
      'method_mask' => -1,
      'requirement' => 'group bar tar'
    }
  ];

The requirement field is what was passed to the CWRequire directive. The method_mask field is a bitmask which can be modified by the CWLimit directive, but normally it can be safely ignored as it's mostly used internally. For example if the configuration was:

    Require user goo bar
    Require group bar tar
    <Limit POST>
       Require valid-user
    </Limit>

and the request method was CWPOST, CW$r->requires will return:

  [
    {
      'method_mask' => -1,
      'requirement' => 'user goo bar'
    },
    {
      'method_mask' => -1,
      'requirement' => 'group bar tar'
    }
    {
      'method_mask' => 4,
      'requirement' => 'valid-user'
    }
  ];

But if the request method was CWGET, it will return only:

  [
    {
      'method_mask' => -1,
      'requirement' => 'user goo bar'
    },
    {
      'method_mask' => -1,
      'requirement' => 'group bar tar'
    }
  ];

As you can see Apache gives you the requirements relevant for the current request, so the method_mask is irrelevant.

It is also a good time to remind that in the general case, access control directives should not be placed within a <Limit> section. Refer to the Apache documentation for more information.

Using the same configuration and assuming that the request was of type POST, the following code inside an Auth handler:

  my %require =
      map { my ($k, $v) = split /\s+/, $_->{requirement}, 2; ($k, $v||'') }
      @{ $r->requires };

will populate CW%require with the following pairs:

  'group' => 'bar tar',
  'user' => 'goo bar',
  'valid-user' => '',

  $satisfy = $r->satisfies();

since: 2.0.00

See the documentation for the CWSatisfy directive in the Apache documentation. Can be used within any handler to determine if any authentication is required for the current request:

  $need_auth = $r->some_auth_required();

since: 2.0.00

mod_perl 2.0 documentation.

mod_perl 2.0 and its core modules are copyrighted under The Apache Software License, Version 2.0.

The mod_perl development team and numerous contributors.