libapa...:Access(3pm)
π NAME π
Apache2::Access β the Perl API for the Apache request object that handles Access, Authentication and Authorization. That's it, that's the whole vibe. π
okay so real talk bestie: this page ships as part of the User Contributed Perl Documentation (the header says libapa...:Access(3pm), which is a whole mood of its own π). It is long, so we're splitting it up and this is part 1. Stay with me, we got this. π«Ά
β¨ SYNOPSIS β¨
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();
# which Options are allowed by AllowOverride (since Apache 2.2)
$allow_override_opts = $r->allow_override_opts();
# 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();
like, look at all those little guys go πβ¨ that's the whole module in one snack-sized block.
π« DESCRIPTION π«
So. The API this module hands you is all about the access, authentication and authorization phases. That's its whole personality, and honestly? iconic. π
Apache2::Access extends Apache2::RequestRec β it's basically RequestRec's cool older cousin who knows all the auth drama. π¦
π¦ API π¦
Apache2::Access provides the following functions and/or methods, and bestie, we're going through every single one. No skipping. Periodt. π
π allow_methods
Specify which HTTP methods are allowed. gatekeeping, but make it configurable. πͺ
$r->allow_methods($reset);
$r->allow_methods($reset, @methods);
- obj:
$r(Apache2::RequestRec object) β the current request, our main character. - arg1:
$reset( boolean ) β pass a true value and every method that was allowed before gets removed (sorry girl, wiped). Pass anything falsy and the list stays exactly as it was. - opt arg2:
@methods( array of strings ) β the HTTP methods you're giving the green light to, like"GET"and"POST"β¨ - ret: no return value β she does the thing and says nothing. mysterious.
- since: 2.0.00
For example: here's how you allow only GET and POST, no matter what the previous setting was:
$r->allow_methods(1, qw(GET POST));
π allow_options
Retrieve the value of Options for this request. π
$options = $r->allow_options();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret:
$options( integer ) β theOptionsbitmask. You'll normally use it with bitlogic operators against theApache2::Const :options constants. π§ - since: 2.0.00
For example if the configuration for the current request was:
Options None
Options Indexes FollowSymLinks
Then 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
see how it's all TRUE TRUE FALSE? vibe check passed. π
π allow_overrides
Retrieve the value of AllowOverride for this request.
$allow_override = $r->allow_overrides();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret:
$allow_override( integer ) β theAllowOverridebitmask. Same deal as before: normally used with bitlogic operators against theApache2::Const :override constants. π - since: 2.0.00
For example if the configuration for the current request was:
AllowOverride AuthConfig
Then 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
π allow_override_opts
Retrieve the bitmask of allowed Options set by AllowOverride Options=... for this request. ποΈ
$override_opts = $r->allow_override_opts();
Enabling single options was introduced in Apache 2.2. For Apache 2.0 this function returns Apache2::Const::OPT_UNSET | Apache2::Const::OPT_ALL | Apache2::Const::OPT_INCNOEXEC | Apache2::Const::OPT_SYM_OWNER | Apache2::Const::OPT_MULTI, which corresponds to the default value (if not set) for Apache 2.2.
ngl that's the old-Apache behaviour of this call, and the set of constants above is exactly what you get back there. no cap, that's just what the page says. π
- obj:
$r(Apache2::RequestRec object) β the current request. - ret:
$override_opts( integer ) β the override options bitmask. Normally used with bitlogic operators against theApache2::Const :options constants. π§ - since: 2.0.3
For example if the configuration for the current request was:
AllowOverride Options=Indexes,ExecCGI
Then the following applies:
use Apache2::Const -compile => qw(:options);
$r->allow_override_opts & Apache2::Const::OPT_EXECCGI; # TRUE
$r->allow_override_opts & Apache2::Const::OPT_SYM_LINKS; # FALSE
ExecCGI said yes, SymLinks said no. we love a decisive queen. π
π auth_name
Get/set the current Authorization realm β that's the per directory configuration directive AuthName. π·οΈ
$auth_name = $r->auth_name();
$auth_name = $r->auth_name($new_auth_name);
- obj:
$r(Apache2::RequestRec object) β the current request. - opt arg1:
$new_auth_name( string ) β if$new_auth_nameis passed, a newAuthNamevalue gets set. slay, new realm just dropped. β¨ - ret:
"$"( integer ) β the current value ofAuthName. - since: 2.0.00
The AuthName directive creates a 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 $r->auth_name, to determine which set of credentials to authenticate. π¦
π auth_type
Get/set the type of authorization required for this request β the per directory configuration directive AuthType. π
$auth_type = $r->auth_type();
$auth_type = $r->auth_type($new_auth_type);
- obj:
$r(Apache2::RequestRec object) β the current request. - opt arg1:
$new_auth_type( string ) β if$new_auth_typeis passed, a newAuthTypevalue gets set. - ret:
"$"( integer ) β the current value ofAuthType. - since: 2.0.00
Normally AuthType would be set to Basic to use the basic authentication scheme defined in RFC 1945, Hypertext Transfer Protocol -- HTTP/1.0. However, you could set it to something else and implement your own authentication scheme. build your own, bestie! π οΈβ¨
π get_basic_auth_pw
Get the password from the request headers. π
my ($rc, $passwd) = $r->get_basic_auth_pw();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret1:
$rc(Apache2::Const constant) βApache2::Const::OKif the$passwdvalue is set (and assured a correct value in$r->user); otherwise it returns an error code β eitherApache2::Const::HTTP_INTERNAL_SERVER_ERRORif things are really confused π,Apache2::Const::HTTP_UNAUTHORIZEDif no authentication at all seemed to be in use, orApache2::Const::DECLINEDif there was authentication, but it wasn'tBasic(in which case, the caller should presumably decline as well). - ret2:
$ret(string) β the password as set in the headers (decoded). - since: 2.0.00
If AuthType is not set, this handler first sets it to Basic. she does it for you, effortless. π
π get_remote_logname
Retrieve the login name of the remote user (RFC1413). π
$remote_logname = $r->get_remote_logname();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret:
$remote_logname( string ) β the username of the user logged in to the client machine, or an empty string if it could not be determined via RFC1413, which involves querying the client's identd or auth daemon. no daemon, no name, sorry. π - since: 2.0.00
Do not confuse this method with $r->user, which provides the username provided by the user during the server authentication. two different girlies, two different jobs. π
π note_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 for both basic and digest authentication. π¨
$r->note_auth_failure();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret: no return value.
- since: 2.0.00
This method requires AuthType to be set to Basic or Digest. Depending on the setting it'll call either $r->note_basic_auth_failure or $r->note_digest_auth_failure. it's giving delegation, honestly. π
π note_basic_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();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret: no return value.
- since: 2.0.00
π 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 digest authentication. π
$r->note_digest_auth_failure();
- obj:
$r(Apache2::RequestRec object) β the current request. - ret: no return value.
- since: 2.0.00
π requires
Retrieve information about all of the requires directives for this request. π
$requires = $r->requires
- obj:
$r(Apache2::RequestRec object) β the current request. - ret:
$requires( ARRAY ref ) β returns an array reference of hash references, containing information related to therequiredirective. - 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 Require directive. The method_mask field is a bitmask which can be modified by the Limit 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 POST, $r->requires will return:
[
{
'method_mask' => -1,
'requirement' => 'user goo bar'
},
{
'method_mask' => -1,
'requirement' => 'group bar tar'
}
{
'method_mask' => 4,
'requirement' => 'valid-user'
}
];
so yeah, -1 masks for the free-range requires and a 4 for the one trapped inside <Limit POST> π«Ά and that's where part 1 leaves us β the rest of the module is coming up in the next part, so don't go anywhere bestie π
okay so if the request method was GET, itβs literally gonna return only this:
[
{
'method_mask' => -1,
'requirement' => 'user goo bar'
},
{
'method_mask' => -1,
'requirement' => 'group bar tar'
}
];
And bestie, the way Apache does it? It gives you the requirements that are relevant for the current request, so the method_mask is irrelevant here β no cap. π
Also, a lil reminder: in the general case, access control directives should not be placed within a <Limit> section. Go check the Apache documentation for more info, iykyk. π
Same config, but say the request was a POST instead β then this code inside an Auth handler:
my %require =
map { my ($k, $v) = split /\s+/, $_->{requirement}, 2; ($k, $v||'') }
@{ $r->requires };
will populate %require with these exact pairs:
'group' => 'bar tar',
'user' => 'goo bar',
'valid-user' => '',
β¨ satisfies β¨
How the requires lines must be met, bestie. Whatβs the applicable value of the Satisfy directive:
$satisfy = $r->satisfies();
- obj:
$r(Apache2::RequestRec object) β the current request π - ret:
$satisfy( integer ) β how the requirements must be met. One of theApache2::Const :satisfy constants:Apache2::Const::SATISFY_ANY,Apache2::Const::SATISFY_ALLandApache2::Const::SATISFY_NOSPECβ¨ - since:
2.0.00
See the documentation for the Satisfy directive in the Apache documentation.
π¦ some_auth_required π¦
Can be used within any handler to determine if any authentication is required for the current request:
$need_auth = $r->some_auth_required();
- obj:
$r(Apache2::RequestRec object) β the current request - ret:
$need_auth( boolean ) βTRUEif authentication is required,FALSEotherwise - since:
2.0.00
π See Also π
mod_perl 2.0 documentation.
π Copyright π
mod_perl 2.0 and its core modules are copyrighted under The Apache Software License, Version 2.0. π«Ά
π Authors π
The mod_perl development team and numerous contributors. π
okay thatβs the whole vibe, bestie β this page is from perl v5.42.3, dated 2026-08-20, and it lives under libapa...:Access(3pm). now go be the main character of your auth configs β¨π
π¦ where this page comes from
- ubuntu stonking: libapache2-mod-perl2 2.0.13-2build3 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms