Apache and mod_rewrite

The mod_rewrite module provides a very helpful, very powerful tool for the administration of web sites. As the name implies, it provides a mechanism to rewrite URLs. Here are a few examples where mod_rewrite comes in handy:

• client redesigns their web site and the programming framework uses different URLs than the previous site but the client needs to maintain "friendly" top-level links, such as http://www.client.com/products and http://www.client.com/support
• client removes a lot of content and would like to use a generic "not found" page to inform the user instead of a regular "404 Not found" page
  
• restrict access to certain content based on an environment variable
  
• set a cookie based on the URL
  
• the client has SSL certificates installed on the web server (not the load balancers) and needs to do redirects to HTTPs for certain pages, additionally, they would like to do this in Apache instead of processing the request with the more heavy-weight Tomcat/Jboss/Weblogic app layer.

The manual for mod_rewrite is available online at http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html and contains many examples.

It is important to remember that the rewrite engine checks patterns first, then checks the condition(s) to see if the pattern should be applied. This is a little backwards from traditional thinking where conditions are checked before applying the logic associated with the conditions.
This example was taken from a client with the following requirements:

• a 3rd party site contains a link to a Opsource-managed web site
  
• any requests coming from the 3rd party site should be allowed through
  
• requests coming from the 3rd party site would be distinguished by a special URI string
  
• all other requests to the site should be denied

The following rewrite rules were put in place. Again, the RewriteRule is checked *before* the RewriteConds are checks. In this case, the RewriteRule is looking at ^.* which matches everything.:

RewriteEngine On
#RewriteLog "logs/tac_rewrite.log"
#RewriteLogLevel 4

RewriteCond %{HTTP_REFERER} !^https://www\.heisenbug\.cop/portal/site/index\.jsp
RewriteCond %{REQUEST_URI} !/286482b67b05ad585cfc99996f5158d7
RewriteCond %{HTTP_REFERER} !^http://www\.mysupersite\.cop.*
RewriteRule ^.* /denied/denied.html [L]

The "RewriteEngine On" simply turns on the rewrite processing engine. The Rewrite log directives specify a log that only the rewrite engine uses and the level of information printed in the log. The first RewriteCond rule checks the environment variable HTTP_REFERER, which is the referring web site, is not set to the 3rd party site. This variable is sent by the browser when you click a link on a page. The second RewriteCond rule checks that the special string is, again, not set in the URI. The third RewriteCond rule checks that the referer variable is not the Opsource-managed site itself. This is necessary for when the user clicks links on the Opsource-managed site.  If any of these conditions are true, the user is redirected to a denied page. The [L] at the end of the ReWriteRule means "stop processing any more rules, this is the last rule."

This seems counterintuitive but fulfills all our requirements because only traffic that comes from the 3rd party web site or contains the special URI string will not be redirected to the denied page, in effect, the proper resource will be delivered to the browser. It should be noted that the HTTP_REFERER and the URI string (used in this example) are easily faked and this should *not* be used as a means of securing a web site. The client was made fully aware of this and they opted for it since they only wanted to prevent "casual" browsing.