Container or Block Directives Oracle Application Server Tips by Burleson Consulting

Container or Block Directives change the configuration within the area defined by the container.  They use the familiar HTML notation, with some restrictions.  Directives must be on their own line.  Container Directives have limited scope and if included directives are outside the scope of the container they will be ignored.  The code sample below demonstrates the basic structure of a Container Directive.

<ContainerType objects>
   list of directives
</ContainerType>

<Directory />
    Options All
    AllowOverride All
</Directory>

The example container is a Directory container for our DocumentRoot directory.  Before we go into detail, let?s discuss the different types of Container Directives and their function.

Directory Container Directives

Directory Container Directives apply only to the named directory and all subdirectories under the named directory.  For this reason, an administrator normally starts by defining a Directory Container for the root directory to setup default directives for all directories that are not explicitly defined.  For example:

<Directory />
    Options FollowSymLinks MultiViews
    AllowOverride None
</Directory>

One alternative to control access to directories is to place a .htaccess file in each subdirectory containing specific directives.  If the AllowOverride is not set to None, OHS will read the .htaccess file and override the directives in the httpd.conf file with the directives in the .htaccess file.  To preclude this, set AllowOverride to None.  Note that we have set AllowOverride to None in the container for the root directory.  This will not preclude us from specifying other directory containers in the httpd.conf file.

AllowOverride only applies to the .htaccess file.  The Options parameter can be set to None, All, a combination of Indexes, FollowSymLinks, ExecCGI, or MultiViews.

None is self-explanatory, as is All, except that All does not include MultiViews.  If you use MultiViews, then you can?t use All and must list each option. 

MultiViews is a nice capability that allows OHS to do an implicit filename search and pick from the results.  For example, if you request the file pictures.html and it does not exist, OHS will look for pictures.html.* and may find pictures.html.en, pictures.html.fr, etc.  OHS will check the mapping for languages and select pictures.html.en, if that is the first language on the language mapping priority.  OHS could also find pictures.html.gz (a compressed file), and either uncompress the file before serving it, or serve it compressed and let the client uncompress it. ExecCGI allows the execution of CGI scripts located in that directory.  FollowSymLinks allows OHS to follow symbolic links to another directory or file.  This does not change the Directory directives it is executing under.  If the symbolic link leads to a directory with different defined options, OHS will continue to execute under the directives of the directory that it came from.  The SymLinksIfOwnerMatch option is the same, except that the target directory or file must be owned by the same user id as the link.  The Indexes option will cause OHS to return a formatted listing of the directory if it fails to find the Index.html file, otherwise it returns an error message.  The Includes option allows server-side includes.  If not set, the options directive defaults to all (excluding MultiViews). 

Normally, an administrator will define all options explicitly, however, for confusion?s sake you can add a ?+? or ??? to an option.  If the option uses a ?+?, as in option +Indexes, then the Indexes option is added to the options of the directories? parent options.  Likewise, the ?-?, as in ?FollowSymLinks, will exclude that option from the options of the directories? parent options.  For example:

<Directory /www/docs>
    Options FollowSymLinks MultiViews
    AllowOverride None
</Directory>
<Directory /www/docs/time>
    Options -FollowSymLinks +Indexes
</Directory>

The directory /www/docs/time has the Indexes and MultiViews options.

Now lets return to the httpd.conf file and look at how the directory containers are defined.  The first step is to define the directives for the root directory, since all other directories are subdirectories of root.  By defining the root directives, we establish default directives for any directories that are not explicitly defined. 

<Directory />
    Options FollowSymLinks MultiViews
    AllowOverride None
</Directory>

Next, the httpd.conf file defines directives for the DocumentRoot directory.

<Directory "/home/oracle/oraportal904/Apache/Apache/htdocs">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

This container contains a couple of new clauses used to limit access to the directory.  Since the container can both limit and grant access, it uses the order clause to direct the order in which grants and limits are evaluated.  In this case, execute the Allow clause or clauses, then the Deny clauses.

Order Deny,Allow
Deny from all
Allow from oracle.com

Here, we first deny access to all users, then allow access to those users from the oracle.com domain.  If the order clause was ?Order Allow, Deny? the result would be to deny access to everyone, including those from oracle.com.  At this point, we should discuss the Limit and LimitExcept Containers.

Limit and LimitExcept Containers

The Limit and LimitExcept containers define directives on HTTP methods.  Limits defines directives on named HTTP methods, while LimitExcept defines directives on all HTTP methods, except those named.

<Limit POST PUT DELETE>
Require valid-user
</Limit>

<LimitExcept POST GET>
Require valid-user
<LimitExcept>

The first example limits the POST, PUT, and DELETE methods to a valid-user.  The second example limits all methods to a valid user, except for the POST and GET methods.  The Limit and LimitExcept Containers should rarely be used.

As we continue through the httpd.conf file, we find a block directive.

Block Directives

Block directives are used to test for an item during the processing of the configuration file.  The directives that they contain are only executed if the test returns true.  If the test returns false then the directives between the block start and end are ignored.  The two types of block directives are <IfModule> and <IfDefined>. 

<IfModule mod_userdir.c>
    UserDir public_html
</IfModule>

<IfDefine ReverseProxy>
  LoadModule rewrite_module libexec/mod_rewrite.so
  LoadModule proxy_module   libexec/libproxy.so
</IfDefine>

If module mod_userdir.c is loaded in the first example, then the variable UserDir is defined as public_html.  If the module is not loaded, then the block is skipped, and UserDir either remains with it?s current definition or is undefined.  In the second example, if ReverseProxy is defined, then load the directed module headers.

It is important to note that Block Directives can be nested and that they do not limit the scope of the contained directives, which execute within the scope of the container in which they were called, as well as globally. 

Files and FilesMatch Containers

The Files and FilesMatch Containers allow for file level access control.  The difference between the Files container and the FilesMatch container is that the FilesMatch container uses regular expressions to identify effected files.  The Files containers are placed after the Directories container in the httpd.conf file, however, they can also be nested inside a Directory container. The following Files Container is located in the httpd.conf file of the OHS.

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

This Files container denies all access to any file that starts with .ht.  Since directories may contain a .htaccess file that contains access information, this Files container insures that no user can request that file.  If the Files container is nested inside a Directories container, then the scope of the Files container directives is limited to the scope of the Directories container.

The use of the ?~? character in the filename allows Files to use regular expressions.  Starting with Apache 1.3, it is preferred to use FilesMatch when regular expressions are needed.  Many directives have a *Match companion. It is preferred to use the *Match version when using regulare expressions rather than the ~ option.   Lastly, the Files and FilesMatch containers can be used in the .htaccess file.

Location Containers

The OHS httpd.conf file contains a number of Location containers spread through the file, so I will give a brief explanation here.  Location containers limit access by URL.  They are normally located after the Files section of the httpd.conf file.  For all origin (non-proxy) requests, the URL to be matched is of the form /path/, and you should not include any http://servername prefix. For proxy requests, the URL to be matched is of the form scheme://servername/path, and you must include the prefix.

<Location /status>
    Order Deny,Allow
    Deny from all
    Allow from .oracle.com
</Location>

Here, access to the /status path is limited only to those requests originating from oracle.com.  For more information on the Location Container, see the Apache documentation.

 

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.