Determining Whether You Need to Specify Additional DNS Names

Sometimes Web pages contain URL references to a host name that does not meet the default criteria for being rewritten. That is, the URL reference does not match the Web Server Host Name or any value (IP address) in the Web Server List. If these names are sent back to the client, they are not resolvable. Figure 13-4 illustrates a scenario that requires an entry in the Additional DNS Name List.

Figure 13-4 Rewriting a URLs for Web Servers

The page on the data.com Web server contains two links, one to an image on the data.com server and one to an image on the graphics.com server. The link to the data.com server is automatically rewritten to novell.com, when rewriting is enabled. The link to the image on graphics.com is not rewritten, until you add this URL to the Additional DNS Name List. When the link is rewritten, the browser knows how to request it, and the Access Gateway knows how to resolve it.

You need to include names in this list if your Web servers have the following configurations:

When you enter a name in the list, it can use any of the following formats:

DNS_name
host_name
IP_address
scheme://DNS_name
scheme://IP_address
scheme://DNS_name:port
scheme://IP_address:port

For example:

HOME
https://www.backend.com
https://10.10.15.206:444

These entries are not case sensitive.

Determining Whether You Need to Exclude DNS Names from Being Rewritten

If you have two reverse proxies protecting the same Web server, the rewriter correctly rewrites the references to the Web server so that browser always uses the same reverse proxy. In other words, if the browser requests a resource using acme.com.uk, the response is returned with references to acme.com.uk and not acme.com.usa. If you have a third reverse proxy protecting a Web server, the rewriting rules can become ambiguous. For example, consider the configuration illustrated in Figure 13-5.

Figure 13-5 Excluding URLs

A user accesses data.com through the published DNS name of novell.com.mx. The data.com server has references to product.com. The novell.com.mx proxy has two ways to get to the product.com server because this Web server has two published DNS names (novell.com.uk and novell.com.usa). The rewriter could use either of these names to rewrite references to product.com.

Types of Rewriter Profiles

The Access Gateway allows you to define two types of profiles:

Page Matching Criteria for Rewriter Profiles

You specify the following matching criteria for selecting the profile:

You use the Requested URLs to Search section of the profile to set up the matching policy.

You can specify two types of URLs. In the If Requested URL Is list, you specify the URLs of the pages you want this profile to match. In the And Requested URL Is Not list, you specify the URLs you don’t want this profile to match. You can use the asterisk wildcard for a URL in the If Requested URL Is list that matches pages you really don’t want this profile to match, then use a URL in the And Requested URL Is Not list to exclude them from matching. If a page matches both a URL in the If Requested URL Is list and in the And Requested URL Is Not list, the profile does not match the page.

For example, you could specify the following URL in the If Requested URL Is list:

http://www.a.com/*

You could then specify the following URL in the And Requested URL Is Not list:

http://www.a.com/content/*

These two entries cause the profile to match all pages on the www.a.com Web server except for the pages in the /content directory and its subdirectories.

Regardless of content-type, the page matches if the file extension is html, htm, shtml, jhtml, asp, or jsp.

Possible Actions for Rewriter Profiles

The rewriter action section of the profile determines the actions the rewriter performs when a page matches the profile. Select from the following:

If your profile needs to match pages from this type of proxy server, you might need to enable the Strip Path from Query String and Strip Path from Post Data options.

The strip path options are not available for a Character profile. If the proxy service is not a path-based multi-homing proxy, the strip path options have no effect.

This option is not available for a Character profile.

This option is not available for a Character profile.

When defining a rewriter profile, you should try to put all the string actions into the Word profile. When a Word profile and a Character profile both match the same URL, you need to ensure that they do not contain search and replace actions for overlapping strings. The results of such actions are unpredictable.

For example, if your Word profile has an action to search for Doodle and replace this string with Artwork and your Character profile has an action to search for Doo and replace this string with Zoo, the results are unpredictable. If you place both search and replace actions in the Word profile, the results are predictable.

For the rules and tokens that can be used in the search strings, see the following:

For information on how the Additional Strings to Replace list can be used to reduce the number of Java methods you need to list, see Using $path to Rewrite Paths in JavaScript Methods, Parameters, or Variables.

String Replacement Rules for Word Profiles

In a Word profile, a string matches all paths that start with the characters in the specified string. For example:

You can use the following special tokens to modify the default matching rules:

[ow]my[w]string[w]to[w]replace[ow]

If you don’t know, or don’t care, whether the string has zero or more white characters at the beginning and at the end, use [ow] to specify this. The [w] specifies exactly one white character.

The [ew] token can be used to match the following types of paths:

String Replacement Rules for Character Profiles

When you configure multiple strings for replacement, the rewriter uses the following rules for determining how characters are replaced in strings:

Using $path to Rewrite Paths in JavaScript Methods, Parameters, or Variables

You can use the $path token to rewrite paths on a path-based multi-homing service that has the Remove Path on Fill option enabled. This token is useful for Web applications that require a dedicated Web server and are therefore installed in the root directory of the Web server. If you protect this type of application with Access Manager using a path-based multi-homing proxy service, your clients access the application with a URL that contains a /path value. The proxy service uses the path to determine which Web server a request is sent to, and the path must be removed from the URL before sending the request to the Web server.

The application responds to the requests. If it uses JavaScript methods, parameters, or variables to generate paths to resources, these paths are sent to client without prepending the path for the proxy service. When the client tries to access the resource specified by the Web server path, the proxy service cannot locate the resource because the multi-homing path is missing. The figure below illustrates this flow with the rewriter adding the multi-homing path in the reply.

Figure 13-6 Rewriting with a Multi-homing Path

To make sure all the paths generated by JavaScript are rewritten, you must search the Web pages of the application. You can then either list all the JavaScript methods, parameters, and variables in the Additional Names to Search for URL Strings to Rewrite with Host Name section of the rewriter profile, or you can use the $path token in the Additional Strings to Replace section. This token, which is a shortcut for the multi-homing path, together with the Strip Path from Query String and Strip Path from Post Data actions, usually can find all the paths that need to rewritten. If nothing else, it reduces the number of JavaScript methods, parameters, and variables that you otherwise need to list individually.

To use the $path token, you add a search string and a replace string that uses the token. For example, if the /prices/pricelist.html page is generated by JavaScript and the multi-homing path for the proxy service is /inner, you would specify the following stings:

This configuration allows the following paths to be rewritten.

If the Strip Path from Query String or Strip Path from Post Data option is enabled, the search and replace strings allow the following paths to be rewritten.

Disabling per Proxy Service

By default, the rewriter is enabled for all proxy services. The rewriter can slow performance because of the parsing overhead. In some cases, a Web site might not have content with URL references that need to be rewritten. The rewriter can be disabled on the proxy service that protects that Web site.

Disabling per URL

You can also specify a list of URLs that are to be excluded from being rewritten for the selected proxy service.

Disabling with Page Modifications

There are cases when the URLs in only part of a page or in some of the JavaScript or form can be rewritten and the rest should not be rewritten. When this is the case, you might need to modify the content on the Web server. Although this deviates from the design behind Access Manager, you might encounter circumstances where it cannot be avoided.

You can add the following types of tags to the pages on the Web server:

These tags are seen by browsers as a comment mark, and do not show up on the screen (except possibly on older browser versions).

<!--NOVELL_REWRITER_OFF--> 
.
.
HTML data not to be rewritten
.
.
<!--NOVELL_REWRITER_ON-->

The last tag is optional, and if omitted, it prevents the rest of the page from being rewritten after the initial tag is encountered.

<!--NOVELL_REWRITE_ATTRIBUTE_ON='value'-->
.
.
<param> elements to be rewritten
.
.
<!--NOVELL_REWRITE_ATTRIBUTE_OFF='value'-->
.
.
<param> elements that shouldn’t be rewritten

<!--NOVELL_REWRITE_ATTRIBUTE_ON='formvalue'-->
.
.
<input>, <button>, and <option> elements to be rewritten
.
.
<!--NOVELL_REWRITE_ATTRIBUTE_OFF='formvalue'-->
.
.
<input>, <button>, and <option> elements that shouldn’t be rewritten