Often times, you may find it necessary to control access to the server, based on certain characteristics of a client request. For example, you may wish to restrict requests based on client's host name, IP address, or some other characteristic. You can use special access control directives in the <Directory>, <Files>, and <Location> containers, as well as in the .htaccess files, to restrict access to particular parts of the OHS server. There are three types of access control directives you can use to restrict access by users. You use the Allow and Deny directives to determine which users are allowed or denied access to the server. A third access directive, Order, determines the default access state, as well as determining the way the Allow and Deny directives will interact. Note that the access restrictions apply to all access methods such as GET, POST, and PUT. However, by enclosing directives inside the <Limit> directive, you can restrict requests using only certain access methods. The all-important access directives are examined in some detail in the following subsections. Allow Using the Allow directive, you can control which host can access an area of the server. You can control access by specifying host names or IP addresses or by some other client characteristics captured through the environmental variables. You always use the keyword from when using the Allow directive (Allow from . . . ), if you choose to specify the value for the Allow directive, as shown here: Allow from all All hosts are allowed access to your server, unless you restrict them by configuring them with the Deny and Order directives, which are discussed in the following subsections. Here's an example showing how to use the Allow directive. By using this directive, you are allowing access from the host with the IP number 10.1.2.3. Allow from 10.1.2.3 Deny The Deny directive restricts access to the server based on the host name, the IP address, or environment variables. The syntax and the arguments for the Deny directive are similar to those of the Allow directive. Here's an example: Deny from 10.1.2.3 The Deny directive here refuses client requests to the OHS server from the IP address 10.1.2.3. Order It's possible to use both Allow and Deny directives together on a Web server. To avoid a confiict between these two directives, you must have some way to specify the precedence rules for applying the Allow and Deny directives. Using the Order directive, you control the default access state for the Web server, as well as the order in which the server will apply the Allow and Deny directives. The Order directive could take the following values (both values are part of the Order specification):
In the following example, only the hosts in the oracle.org domain are allowed access, and all the other hosts are denied access. Order Deny,Allow In this example, all hosts in the oracle.org domain are allowed access, except for the hosts in the test.oracle.org subdomain. The latter group is denied access by the Deny directive (Deny from test.oracle.org). All hosts that aren't in the oracle.org domain are denied access, because by default, the Allow, Deny order means that access is denied to the OHS server. Order Allow,Deny In this example, I use the same domains and sub domains as before for the Allow and Deny directives, but reverse the order to Deny, Allow. Order Deny,Allow Now, all hosts are allowed access to the OHS server, because although the Allow and Deny directives are listed in that order, Deny will be evaluated first. OHS evaluates the Allow directive last, and this will override the Deny directive, which specifies that requests from the test.oracle.org subdomain will be denied. Not only will all hosts in the oracle.org domain be allowed access (inasmuch as the Allow directive specifies that), but all hosts from any domain are allowed access, because the default access state of Deny< Allow is to allow access.
blog comments powered by Disqus |
|
|
|
|
|
|
|