{"id":5977,"date":"2016-06-23T08:08:11","date_gmt":"2016-06-23T00:08:11","guid":{"rendered":"http:\/\/rmohan.com\/?p=5977"},"modified":"2016-06-23T08:08:11","modified_gmt":"2016-06-23T00:08:11","slug":"access-authorization-in-apache-2-4","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=5977","title":{"rendered":"Access authorization in Apache 2.4"},"content":{"rendered":"

In Apache 2.4 the authorization configuration setup has changed from previous versions. Satisfy, Order, Deny and Allow have all been deprecated and replaced with new Require<\/a> directives.<\/p>\n

Below we’ve compiled some examples to guide you through the transition.<\/p>\n

If you are upgrading a server using the legacy authorization directives you can make them work quickly by enabling (it should be activated by default) mod_access_compat<\/tt> in Apache:<\/b><\/p>\n

sudo a2enmod access_compat<\/code><\/p>\n

1. Apache Documentation<\/h2>\n

The documentation from Apache: Upgrading to 2.4 from 2.2<\/a> provides the following basic examples. The old configuration settings are on the left, and the new ones for Apache 2.4 on the right:<\/p>\n

All requests are denied:<\/h4>\n

Order<\/b> deny,allow Deny<\/b> from all<\/code>Require<\/b> all denied<\/code><\/p>\n

<\/div>\n

All requests are allowed:<\/h4>\n

Order<\/b> allow,deny Allow<\/b> from all<\/code>Require<\/b> all granted<\/code><\/p>\n

<\/div>\n

Only hosts in the example.org domain are allowed access:<\/h4>\n

Order<\/b> Deny,Allow Deny<\/b> from all Allow<\/b> from example.org<\/i><\/code>Require<\/b> host example.org<\/code><\/p>\n

<\/div>\n

But this only scratches the surface of what’s now available.<\/p>\n

2. RequireAll and RequireAny<\/h2>\n

The most interesting new features are the RequireAll<\/tt>, RequireAny<\/tt> and RequireNone<\/tt> authorization containers. They promise to be both more powerful and more human-readable than the old syntax.<\/p>\n

By default all Require directives are handled as though contained within a <RequireAny><\/tt>container directive. In other words, if any of the specified authorization methods succeed, then authorization is granted.<\/b><\/p>\n

Here is real world example where a website limits access by requiring a Basic Authentication login for certain directories:<\/p>\n

AuthType Basic AuthName \"Password Protected\" AuthUserFile <path_to_your_htpasswd_file> SetEnvIf<\/b> REQUEST_URI \"^\/(admin|secure)\/\" PROTECTED Deny<\/b> from all Satisfy<\/b> any Allow<\/b> from env=!PROTECTED Require<\/b> valid-user<\/code>SetEnvIf<\/b> REQUEST_URI \"^\/(admin|secure)\/\" PROTECTED <RequireAny> <RequireAll> Require not<\/b> env PROTECTED Require<\/b> all granted <\/RequireAll> <RequireAll> AuthType Basic AuthName \"Password Protected\" AuthUserFile <path_to_your_htpasswd_file> Require<\/b> valid-user <\/RequireAll> <\/RequireAny><\/code><\/p>\n

<\/div>\n

In both cases we set an environmental variable PROTECTED<\/tt> when the request is for a file in the \/admin\/<\/tt>or \/secure\/<\/tt> directories. The syntax for this part hasn’t changed. If this variable is set, then a password will be required for access.<\/p>\n

While the old syntax works, it’s not immediately clear how it works. Basically to get access the request has to meet (Satisfy) either the Allow<\/tt> or the Require<\/tt> directive.<\/p>\n

In the new syntax this is more explicit. The request needs to pass at least one (RequireAny<\/tt>) of the twoRequireAll<\/tt> container rulesets. The first container grants all users access to non-PROTECTED directories, while the second container requires a valid login.<\/p>\n

You can keep nesting containers until all possible options are covered.<\/p>\n

But seeing as the outer <RequireAny><\/tt> is already implied, we should be able to remove it. Actually we can remove quite a bit now that we know what we’re doing:<\/p>\n

AuthType Basic AuthName \"Password Protected\" AuthUserFile <path_to_your_htpasswd_file> SetEnvIf<\/b> REQUEST_URI \"^\/(admin|secure)\/\" PROTECTED <RequireAll> Require not<\/b> env PROTECTED <\/RequireAll> Require<\/b> valid-user <\/code><\/p>\n

Note that any Require not<\/tt> directives must always be enclosed in a RequireAll<\/tt> directive. Otherwise you will see an alert logged:<\/p>\n

[core:alert] ...<\/i> negative Require directive has no effect in <RequireAny> directive<\/code><\/p>\n

See further down the page a version of this example that does away with the ENV variable entirely by using an expr<\/tt> condition.<\/b><\/p>\n

3. Require authorization providers<\/h2>\n

The Require directive comes with a number of build-in authorization providers, including some already demonstrated above. Different modules provide different methods.<\/p>\n

The following are provided by the mod_authz_core<\/a> module:<\/p>\n

all<\/h4>\n

Replaces Allow from all<\/tt> and Deny from all<\/tt> in the old syntax:<\/p>\n

Require<\/b> all granted<\/code>Require<\/b> all denied<\/code><\/p>\n

env<\/h4>\n

Require<\/b> env safe_zone<\/i><\/code><RequireAll> Require not<\/b> env PROTECTED<\/i> <\/RequireAll><\/code><\/p>\n

method<\/h4>\n

This example allows only GET and HEAD requests unless you are logged in:<\/p>\n

<RequireAny> Require<\/b> method GET HEAD Require<\/b> valid-user <\/RequireAny><\/code><\/p>\n

The <RequireAny><\/tt> container is not necessary here, but included for clarity:<\/p>\n

expr<\/h4>\n

Require<\/b> expr %{HTTP_USER_AGENT} != 'BadBot'<\/code><\/p>\n

The following options are provided by the mod_authz_host<\/a> module:<\/p>\n

local<\/h4>\n

Require<\/b> local<\/code><\/p>\n

ip<\/h4>\n

<RequireAll> Require<\/b> ip 192.168.1.0\/24<\/i> Require not<\/b> ip 192.168.1.104<\/i> <\/RequireAll><\/code>Require<\/b> ip 2001:db8:1:1::\/64<\/code><\/p>\n

host<\/h4>\n

<RequireAll> Require<\/b> host example.org<\/i> Require not<\/b> host blocked.example.org<\/i> <\/RequireAll><\/code><\/p>\n

4. Working with expressions<\/h2>\n

After a bit of messing about we were able to further simplify the previous example by removing theSetEnvIf<\/tt> clause and replacing it with a Require expr<\/tt> regular expression condition.<\/p>\n

AuthType Basic AuthName \"Password Protected\" AuthUserFile <path_to_your_htpasswd_file> SetEnvIf<\/b> REQUEST_URI \"^\/(admin|secure)\/\" PROTECTED <RequireAll> Require not<\/b> env PROTECTED <\/RequireAll> Require<\/b> valid-user<\/code>AuthType Basic AuthName \"Password Protected\" AuthUserFile <path_to_your_htpasswd_file> Require<\/b> expr %{REQUEST_URI} !~ m#^\/(admin|secure)\/# Require<\/b> valid-user <\/code><\/p>\n

<\/div>\n

The tricky part was working out how to include the forward slash \/<\/tt> in the regular expression. The solution is instead of the default format which doesn’t allow a forward slash in the match:<\/p>\n

Require<\/b> expr %{REQUEST_URI} !~ \/expr<\/i>\/<\/code><\/p>\n

To use the alternative syntax:<\/p>\n

Require<\/b> expr %{REQUEST_URI} !~ m#expr<\/i>#<\/code><\/p>\n

For details on other SERVER variables and comparison operators that can be used see the link under References below.<\/p>\n

5. Granting local access<\/h2>\n

Another real world example is granting access only to the local network.<\/p>\n

In this case we’re defining the local network as the server itself (localhost), plus the 192.168.1.* subnet covering 192.168.1.0 – 192.168.1.255.<\/p>\n

<Directory \"\/path\/to\/your\/website\"> Options FollowSymlinks AllowOverride None Order allow,deny Allow from 127.0.0.0\/8 192.168.1 ::1 <\/Directory><\/code><Directory \"\/path\/to\/your\/website\"> Options FollowSymlinks AllowOverride None Require<\/b> local Require<\/b> ip 192.168.1 <\/Directory><\/code><\/p>\n

<\/div>\n

The local<\/tt> Require’ment matches requests from the local host over IPv4 or IPv6 (so including 127.0.0.1\/8 and ::1). We wrap this, along with Require ip 192.168.1<\/tt>, in a RequireAny<\/tt> authorization container because we want to accept connections that match either condition.<\/p>\n

We could also write 192.168.1.0\/24 instead of just 192.168.1, but they have the same effect.<\/p>\n

If you want to also allow connections from outside the local network, but requiring authentication, the configuration becomes:<\/p>\n

<Directory \"\/path\/to\/your\/website\"> Options FollowSymlinks AllowOverride None Require<\/b> local Require<\/b> ip 192.168.1 Require<\/b> valid-user <\/Directory><\/code><\/p>\n

So we’re now granting access from localhost and the local network without authentication, plus from all other locations, but then requiring authentication.<\/p>\n

You can make this more secure by restricting outside access to only recognised locations:<\/p>\n

<Directory \"\/path\/to\/your\/website\"> Options FollowSymlinks AllowOverride None Require<\/b> local Require<\/b> ip 192.168.1 <RequireAll> Require<\/b> host example.org Require not<\/b> host badhost.example.org Require<\/b> valid-user <\/RequireAll> <\/Directory><\/code><\/p>\n

Now an external connection can only come from *.example.org and only in conjunction with a valid login. To specify more than one domain or ip address in addition to example.org they will need to be wrapped in yet another container:<\/p>\n

<Directory \"\/path\/to\/your\/website\"> Options FollowSymlinks AllowOverride None Require<\/b> local Require<\/b> ip 192.168.1 <RequireAll> <RequireAny> Require<\/b> host example.org example.com Require<\/b> ip 8.8.8.8 <\/RequireAny> Require not<\/b> host badhost.example.org Require<\/b> valid-user <\/RequireAll> <\/Directory><\/code><\/p>\n

For those getting confused, RequireAll<\/tt> means that all the requirements in that container need to be met, while RequireAny<\/tt> means that only one or more of the contained requirements needs to be met:<\/p>\n

Require<\/b> (local) OR (ip 192.168.1) OR [ [ (host example.org) OR (host example.com) OR (ip 8.8.8.8) ] AND (NOT host badhost.example.com) AND (valid-user) ]<\/code><\/p>\n

6. Public file in Private directory<\/h2>\n

Thank you to Alfredo for this question – how to have a password-protected directory (or website) but allow access to a specific file.<\/p>\n

If you have a directory ~\/private\/<\/tt> then you can make the entire directory secure by adding an.htaccess<\/tt> file ~\/private\/.htaccess<\/tt> with:<\/p>\n

AuthType Basic AuthName \"Password Required\" AuthUserFile \/path\/to\/<\/i>.htpasswd Require<\/b> valid-user<\/code><\/p>\n

But what if there is a file ~\/private\/public.html<\/tt> that you want to make globally accessible? This wasn’t possible in earlier versions of Apache, but can be done now quite simply:<\/p>\n

AuthType Basic AuthName \"Password Required\" AuthUserFile \/path\/to\/<\/i>.htpasswd Require<\/b> expr %{REQUEST_URI} = \"\/private\/public\\.html\" Require<\/b> valid-user<\/code><\/p>\n

How does it work? Remember that there is an explicit <RequireAny><\/tt> wrapped around the two Require<\/tt>statements, so it reads as: either<\/i> the request is for the file public.html<\/tt> or<\/i> require a password.<\/p>\n","protected":false},"excerpt":{"rendered":"

In Apache 2.4 the authorization configuration setup has changed from previous versions. Satisfy, Order, Deny and Allow have all been deprecated and replaced with new Require directives.<\/p>\n

Below we’ve compiled some examples to guide you through the transition.<\/p>\n

If you are upgrading a server using the legacy authorization directives you can make them work quickly […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5977"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5977"}],"version-history":[{"count":1,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5977\/revisions"}],"predecessor-version":[{"id":5978,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/5977\/revisions\/5978"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}