July 8, 2021 . 8 MIN READ
In this step, we will use a built-in package installer called apt-get. It simplifies management drastically and facilitates a clean installation.
First, update the system’s package index. This will ensure that old or outdated packages do not interfere with the installation.
Apache2 is the aforementioned HTTP server and the world’s most commonly used. To install it, run the following:
For information on the differences between Nginx and Apache2, the two most popular open-source web servers, see this article.
Now, we need to activate mod_rewrite.
This will activate the module or alert you that the module is already in effect. To put these changes into effect, restart Apache.
In this section, we will setup a .htaccess file for simpler rewrite rule management.
A .htaccess file allows us to modify our rewrite rules without accessing server configuration files. For this reason, .htaccess is critical to your web application’s security. The period that precedes the filename ensures that the file is hidden.
We will need to set up and secure a few more settings before we can begin.
First, allow changes in the .htaccess file. Open the default Apache configuration file using nano or your favorite text editor.
Inside that file, you will find the <VirtualHost *:80> block on line 1. Inside of that block, add the following block:
<Directory /var/www/html>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
Your file should now match the following. Make sure that all blocks are properly indented.
<VirtualHost *:80>
<Directory /var/www/html>
. . .
</Directory>
. . .
</VirtualHost>
To put these changes into effect, restart Apache.
Now, create the .htaccess file.
Add this first line at the top of the new file to activate the RewriteEngine.
RewriteEngine on
Save and exit the file.
To ensure that other users may only read your .htaccess, run the following command to update permissions.
You now have an operational .htaccess file, to govern your web application’s routing rules.
In this section, we will set up a basic URL rewrite, which converts pretty URLs into actual paths to code. Specifically, we will allow users to access example.com/about.
We will begin by creating a file named about.html.
Copy the following code into the HTML page.
<html>
<head>
<title>About Us</title>
</head>
<body>
<h1>About Us</h1>
</body>
</html>
You may access your web application at your_server_ip/about.html or example.com/about.html. Now notice that only about.html is accessible; if you try to access your_server_ip/about, you will get a Not Found error. We would like users to access about instead. Our rewrite rules will allow this very functionality.
Open up the .htaccess file.
After the first line, add the following.
RewriteRule ^about$ about.html [NC]
Your file should now be identical to the following.
RewriteEngine on
RewriteRule ^about$ about.html [NC]
Congratulations. You can now access example.com/about in your browser!
This is a good simple example that shows the general syntax that all Rewrite Rules follow.
^about$ is the string that gets matched from the URL. That is, it’s what the viewer types in her browser. Our example uses a few metacharacters.
^ indicates the start of the URL, after example.com/ is stripped away.$ indicates the end of the URLabout matches the string “about”about.html is the actual path that the user accesses; that is, Apache will still serve the about.html file.
[NC] is a flag that ignores capitalization in the URL.
With the rule shown above, the following URLs will point to about.html:
example.com/aboutexample.com/Aboutexample.com/about.htmlThe following will not:
example.com/about/example.com/contactIn this section, we will show some commonly-used directives.
Your web application is now running and is governed by a protected .htaccess file. The simplest example was included above. We will explore an additional two examples in this section.
You can set up example files at the result paths if you would like, but this tutorial does not include creating the HTML and PHP files; just the rules for rewriting.
All RewriteRules abide by the following format:
RewriteRule pattern substitution [flags]
RewriteRuleWeb applications often make use of query strings, which are appended to a URL using the ? question mark and delimited using the & ampersand. These are ignored when matching rewrite rules. However, sometimes query strings may be required for passing data between pages. For example, a search result page written in PHP may utilize something akin to the following:
http://example.com/results.php?item=shirt&season=summer
In this example, we would like to simplify this to become:
http://example.com/shirt/summer
Example 1A: Simple Replacement
Using a rewrite rule, we could use the following:
RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer
The above is fairly self-explanatory, as it actually maps shirt/summer to results.php?item=shirt&season=summer. This achieves our desired effect.
Example 1B: Matching Options
However, we would like to generalize this to include all seasons. So, we will do the following:
| boolean, meaning “OR”(), then reference the group using $1, with 1 for the first matched groupThe Rewrite Rule now becomes:
RewriteRule ^shirt/(summer|winter|fall|spring) results.php?item=shirt&season=$1
The rule shown above matches a URL of shirt/ followed by a specified season. That season is grouped using () and then referenced with the $1 in the subsequent path. This means that, for example, that:
http://example.com/shirt/winter
becomes:
http://example.com/results.php?item=shirt&season=winter
This also achieves the desired effect.
Example 1C: Matching Character Sets
However, we would also like to specify any type of item, not just URLs at /shirt. So, we will do the following:
[] matches any character inside of it, and the + matches any number of characters specified in the brackets$2 as the second variable in the file
RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2
The above will convert, for example:
http://example.com/pants/summer
to:
http://example.com/results.php?item=pants&season=summer
Example 1D: Passing Query Strings
This section doesn’t introduce any new concepts but addresses an issue that may come up. Using the above example, say we would like to redirect http://example.com/pants/summer but will pass an additional query string ?page=2. We would like the following:
http://example.com/pants/summer?page=2
to map to:
http://example.com/results.php?item=pants&season=summer&page=2
If you were to attempt to access the above URL with our current settings, you would find that the query string page=2 got lost. This is easily fixed using an additional QSA flag. Modify the rewrite rule to match the following, and the desired behavior will be achieved.
RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA]
RewriteCond lets us add conditions to our rewrite rules. All RewriteConds abide by the following format:
RewriteCond TestString Condition [Flags]
RewriteCond directiveIf a RewriteCond evaluates to true, the RewriteRule immediately following will be considered.
Example 2A: Default Page
In an imaginary administration panel, we may want to direct all malformed URLs back to the home page, instead of greeting users with a 404. Using a condition, we can check to see if the requested file exists.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^admin/(.*)$ /admin/home
This will redirect something like /admin/blargh to /admin/home.
With the above:
%{REQUEST_FILENAME} is the string to check!-f uses the ! not operator on the filenameRewriteRule redirects all requests back to /admin/homeNote that a more syntactically and technically correct approach would be to define the 404 ErrorDocument.
ErrorDocument 404 /error.html
Example 2B: IP Access Restriction
Although this can also achieved using other methods, a RewriteCond can be used to restrict access to one IP or a collection of IP addresses.
This example blocks traffic from everywhere except 12.34.56.789.
RewriteCond %{REMOTE_ADDR} !^(12\.34\.56\.789)$
RewriteRule (.*) - [F,L]
This example is simply the negation of Example 3 from the old mod_rewrite article. The entire statement reads “if the address is not 12.34.56.789, do not allow access.”
In short:
%{REMOTE_ADDR} is the address string!^(12\.34\.56\.789)$ escapes all . periods with a \ backslash and negates the IP address using !F flag forbids access, and the L flag indicates that this is the last rule to run, if executedIf you’d rather block 12.34.56.789, use this instead:
RewriteCond %{REMOTE_ADDR} ^(12\.34\.56\.789)$
RewriteRule (.*) - [F,L]
You can find more rewrite rules, and how to prevent hot linking, in the original article’s part 1 and part 2.
mod_rewrite can be used effectively to ensure human-readable URLs. The .htaccess file itself has many more uses than simply this module, however, and it should be noted that many other Apache modules may be installed to extend its functionality.
There are other resources that detail the capabilities of mod_rewrite:
mod_rewrite is a critical module for web application security, but can sometimes end up in redirect loops or ubiquitous, ambiguous 500 forbidden errors. For tips on debugging .htaccess, see this StackOverflow post.
Rewrite rules are written with regular expressions. To become an expert, reference this tutorial all about regular expressions.
https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_rewrite-for-apache-on-ubuntu-14-04