The Resource Manager lets you configure specific aspects of the proxy server. You choose or create a resource to modify, click the Submit this form button to see a list of options you can configure, and then click a link to the option you want to change for that resource.
|Tip: To map URLs to mirror sites, use the URL Management page.|
A resource can be a single URL, a wildcard pattern that specifies many URLs, or your entire proxy server. A resource is simply a bunch of URLs that are grouped together and have a common configuration. For example, you might want to inhibit caching of certain URLs or specify different cache parameters for certain URLs.
You can configure the entire proxy server, choose an existing resource from a list, or create one by typing a wildcard pattern that matches only the resources you want to configure. See Table 4-1 for a list of examples.
What it Configures
All FTP requests.
All HTTP requests.
All Gopher requests.
All requests containing the exact string party.
Any request for documents on the home.sgi.com host.
All SSL (secure) transactions to HTTPS port.
After you choose a resource, click the Submit this form button. A list of options you can change for the resource you chose appears. Click the link to change the option.
|Note: You must restart the server after you configure resources.|
This section describes the options you can configure for each resource. Keep in mind that not all options are available for every resource.
This option lets you turn off proxying for the resource you chose. This means you can restrict access to one or more URLs by turning off proxying for that resource. This isa global way to deny all access to a resource.
This form tells you the resource you are modifying.
Enable proxying of this resource means the proxy lets clients access this resource (providedthey pass the other security and authorization checks). When you enable proxying for a resource, you can select specific methods to proxy. For example, you might allow all HTTP GETs to be proxied, but you restrict all POSTs. The methods include GET, HEAD, POST, and CONNECT (for SSL proxying).
Disable proxying of this resource means no one can use the proxy to retrieve this resource.
This option takes you to the Access Control form where you can specify which users can access the resource you chose (based on hostnames or IP addresses). The level of restricting access is more specific than enabling or disabling proxying for a resource because you can specify exactly who can get to a resource (whereas enabling and disabling works for anyone who has access to the proxy).
|Tip: If you want to specify only a certain host that is not allowed, start the pattern with *~.|
You can specify a wildcard pattern of host names or IP addresses that are allowed to access this resource through this proxy server. For example, to allow only users from the sgi.com domain, you would use:
Allowed hosts: *.sgi.com
You can also remove the restrictions by checking the option called “Remove these host settings”, use default access control for this resource. See “Access Control” for more information on using Access Control.
Proxy user authentication restricts user access through the proxy. The proxy makes users type in a username and password before giving them access through the proxy (the usernames and passwords are stored in proxy user databases). After users type their name and password, they aren't asked to re-enter the information during that browsing session (the Netscape Navigator remembers the password).
The easiest way to enforce proxy user authentication is to enable it in the entire server, which means that all proxy users must authenticate themselves. If you don't want every user authenticating themselves, you can make users authenticate themselves only when they select a specific resource (URL).
The Proxy user authentication transmits usernames and passwords without encryption. This isn't a problem if you have a trusted network in between your proxy and its clients (for example, your users are on a closed company network).
Before the proxy can use user authentication, you need to create a user database (see “Creating a User Database”). The database lists all the users (and their passwords) who have access to this authenticated resource.
To enable user authentication, set the following options:
User database is the name of the database the proxy uses when authenticating users before giving them access to the resource (URL).
Realm is a text string that the user's client program (Netscape Navigator) displays so that the user can identify which proxy server they are authenticating to. For example, the realm in the administration database is “Proxy Server Administration.”
Allowed users is a wildcard pattern of users in the database that you want to have access to the resource. For example, * would be all of the users in database, k* would be only the users whose username started with the letter K, and (ari|nathan|darin) would allow three users named ari, nathan, or darin.
You can also specify a wildcard pattern of hosts or IP addresses that can access the resources without proper user authentication. This lets local users view the documents in the resource, but restricts access to a limited set of offsite people.
Exempted hosts is a wildcard pattern of hostnames you want to have unlimited access to the resource. For example, you could type *.sgi.com.
Exempted IP addresses is a wildcard pattern of dotted IP addresses that you want to give access to the selected resource. For example, you could type 198.95.251.*.
You can control which resources the proxy caches, provided more general caching options are set. The most general caching option is caching entire protocols (set up through the Proxy Manager configuration forms). The next detail of caching is the caching strategy, and the finest detail is caching based on resources.
See Chapter 5 for more information on caching.
|Note: Cached queries only work with HTTP documents.|
The same caching restrictions still apply: the access method has to be GET, the document must not be protected, and the response must have at least a Last-modified header or an Expires header. This requires the query engine to indicate that the query result document can be cached. If only the Last-modified header is present, the query engine should support conditional GET method (with an If-modified-since header) in order to make caching effective; otherwise it should return an Expires header.
To disable caching queries for this resource, choose Queries Not Cached in the list of numbers of characters per query.
To enable caching queries for this resource, specify the maximum length in characters for queries you want to cache. Longer queries aren't cached.
By default, the proxy caches all documents. If you don't want the resource cached, check “Do not cache this resource”.
If you choose to cache this resource, you can specify how you want it cached. The proxy can always check that the document is up to date, or it can do the up-to-date check only if the document is expired.
See Chapter 5 for more information on caching and caching options.
You can have the proxy access another proxy for some resources instead of accessing the remote server. This means you can chain proxies together. Chaining is a good way to organize several proxies behind a firewall. It also lets you build hierarchical caching. Figure 4-1 illustrates how each proxy server has a small cache that a specific group of users has access to. Each proxy also has access to the proxy with the large cache.
To use a SOCKS daemon to retrieve URLs matching the selected resource, type the SOCKS server hostname and port number. See “SOCKS Daemon Configuration” for more information about SOCKS daemons.
Ordinarily, the proxy responds and sends a message to the client. This message is generic and not always helpful to the user.
You can't customize errors that occur when the proxy is contacting a remote server. Those errors are generated on the fly by the proxy, which tries to make them as informative as possible by using all the dynamic data available.
Customizable errors are
401 Unauthorized (for Administration forms only). The server requires HTTP user authorization to allow access to the Administration forms, and the client either provided none or its HTTP authorization was insufficient.
403 Forbidden. The user tried to access a file or directory for which permission is never allowed.
404 Not Found. The client asked for a filesystem path that doesn't exist or the server was configured to tell the client that it doesn't exist. If you use access control, changing the response to this error lets you tell people nicely that they don't have that access to your proxy.
407 Proxy Authorization Required. The proxy requires proxy authorization, and the client either didn't provide any, or it was insufficient. Also, the client software might not support proxy authorization. The Netscape Navigator version 1.1 (and newer versions) supports this authorization.
500 Server Error. Server errors mean that an error has occurred within the server that prevents it from finishing the request. Server errors mainly happen because of misconfiguration, CGI programs exiting early or otherwise failing, or host resources such as swap space being exhausted.
You can remove resources from the proxy. When you select a resource and use this form, you remove the entire resource and all of its settings (because resources are objects in the obj.conf file, this form deletes the object and its settings from the obj.conf file).
|Caution: Be careful of the resources you remove. You shouldn't remove the HTTP, FTP, or Gopher resources unless you want to entirely disable proxying for them.|
This form is the same as the one you'd see if you chose the Cache Manager from the Administration forms and used the same wildcard pattern as the resource. See “Using the Cache Manager” for more information on this option.
You can expire all documents for a resource. Doing this means the next time the proxy receives a request for the document, it does an up-to-date check and possibly refreshes the document from the remote server. This guarantees that the document will be current. FTP and Gopher documents are automatically refreshed the next time they are requested because there is no way to do up-to-date checks on those types of documents.