X-Git-Url: https://granicus.if.org/sourcecode?a=blobdiff_plain;f=docs%2Fmanual%2Fupgrading.html.en;h=ad6b4540aaf8bcc6657ee58f53098adeba3e9ba7;hb=f0348fc28341bfdcce16cbf8c7d736de12ff85da;hp=c4c0f36f47a850c53cacf4fffbd62e30364022ba;hpb=958711b8724ca63af9e86711ec837561767e905e;p=apache diff --git a/docs/manual/upgrading.html.en b/docs/manual/upgrading.html.en index c4c0f36f47..ad6b4540aa 100644 --- a/docs/manual/upgrading.html.en +++ b/docs/manual/upgrading.html.en @@ -18,7 +18,7 @@

Modules | Directives | FAQ | Glossary | Sitemap

Apache HTTP Server Version 2.5

-
+
<-
Apache > HTTP Server > Documentation > Version 2.5

Upgrading to 2.4 from 2.2

@@ -51,7 +51,7 @@
  • Third Party Modules
  • Common problems when upgrading

    • See also

    + Apache HTTP Server 2.4
  • Comments
    • top

    Compile-Time Configuration Changes

    @@ -138,24 +138,33 @@ although for compatibility with old configurations, the new module mod_access_compat is provided.

    +

    Mixing old and new directives

    +

    Mixing old directives like Order, Allow or Deny with new ones like + Require is technically possible + but discouraged. mod_access_compat was created to support + configurations containing only old directives to facilitate the 2.4 upgrade. + Please check the examples below to get a better idea about issues that might arise. +

    +
    +

    Here are some examples of old and new ways to do the same access control.

    -

    In this example, all requests are denied.

    +

    In this example, there is no authentication and all requests are denied.

    2.2 configuration:

    Order deny,allow
 Deny from all

    2.4 configuration:

    Require all denied
    -

    In this example, all requests are allowed.

    +

    In this example, there is no authentication and all requests are allowed.

    2.2 configuration:

    Order allow,deny
 Allow from all

    2.4 configuration:

    Require all granted
    -

    In the following example, all hosts in the example.org domain +

    In the following example, there is no authentication and all hosts in the example.org domain are allowed access; all other hosts are denied access.

    2.2 configuration:

    Order Deny,Allow
@@ -164,8 +173,113 @@ Allow from example.org

    2.4 configuration:

    Require host example.org
    + +

    In the following example, mixing old and new directives leads to + unexpected results.

    + +

    Mixing old and new directives: NOT WORKING AS EXPECTED

    DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Order deny,allow
+    Deny from all
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Require 127.0.0.1
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
    +
    +

    Why httpd denies access to servers-status even if the configuration seems to allow it? + Because mod_access_compat directives take precedence + over the mod_authz_host one in this configuration + merge scenario.

    + +

    This example conversely works as expected:

    + +

    Mixing old and new directives: WORKING AS EXPECTED

    DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Require all denied
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Order deny,allow
+    Deny from all
+    Allow From 127.0.0.1
+</Location>
+
+access.log - GET /server-status 200 127.0.0.1
    +
    +

    So even if mixing configuration is still + possible, please try to avoid it when upgrading: either keep old directives and then migrate + to the new ones on a later stage or just migrate everything in bulk. +

    +

    In many configurations with authentication, where the value of the + Satisfy was the default of ALL, snippets + that simply disabled host-based access control are omitted:

    + +

    2.2 configuration:

    Order Deny,Allow
+Deny from all
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    2.4 configuration:

    # No replacement needed
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    + +

    In configurations where both authentication and access control were meaningfully combined, the + access control directives should be migrated. This example allows requests meeting both criteria:

    +

    2.2 configuration:

    Order allow,deny
+Deny from all
+# Satisfy ALL is the default
+Satisfy ALL
+Allow from 127.0.0.1
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    2.4 configuration:

    AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+<RequireAll>
+  Require valid-user
+  Require ip 127.0.0.1
+</RequireAll>
    +
    + +

    In configurations where both authentication and access control were meaningfully combined, the + access control directives should be migrated. This example allows requests meeting either criteria:

    +

    2.2 configuration:

    Order allow,deny
+Deny from all
+Satisfy any
+Allow from 127.0.0.1
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    2.4 configuration:

    AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+# Implicitly <RequireAny>
+Require valid-user
+Require ip 127.0.0.1
    +
    +

    Other configuration changes

    @@ -405,7 +519,7 @@ var comments_identifier = 'http://httpd.apache.org/docs/trunk/upgrading.html'; } })(window, document); //-->