Apache Rewrite Module
The mod_rewrite Apache module is one of the best tools you can have on your server to help prevent unauthorized sites "hotlinking" your images or other files. Providing that your server has been set up for it, you can use this module for a number of things.
To prevent unauthorised use of files and images
To hide the real location of files on the server
To translate script input from one format to another
To redirect the user based on...
time of day
file they accessed
network they are connecting from
or anything else that can identify them as part of a "group" of users
Preventing Hotlinking
The most common use of the RewriteEngine is to limit access to specific file types on the server. To do this, you will need to add some rules and conditions to your .htaccess file so that the server knows what to look for and what to do when it finds requests that don't meet the criteria.
When editing your .htaccess file it is recommended that you use Notepad or equivalant to keep the file clean. Remember to upload the file in ASCII mode!
Here is a generic version of the code you will want to use. Of course you will need to make changes before it will work the way you want it to; replace all instances of you.com with your own domain name and add or remove file types as you see fit.
How does it Work?
It's all very well having the code, but you may be interested to know how it works so that you can have a go at editing it to behave more like you want it to. If you ever want to disable the rules, it is much better to use the Rewriteengine statement to switch them off as opposed to commenting them out or deleting them from your file.
The RewriteCond lines tells the server to look for requests with HTTP_REFERER strings that are not empty and that match valid uses of your domain as you define them in the file.
The ! at the start of the condition pattern means not, and so negates the result of the pattern that follows it. ^ and $ are special characters used to match the start and the end of the string in question. So the pattern ^http:// would look for strings starting in http:// and gif$ would match strings ending in gif. The sequence .* will match any character for 0 or more times, and so adding it to the start or end of a particular string will allow fuzzy pattern matching of sorts.
The [NC] flag at the end of the RewriteCond lines tells the server to ignore the case (no case) while looking for matches.
The RewriteRule line tells the server how to deal with the requests that match the condition. In this case it is looking for requests to image files that end in .gif or .jpg (either in all capital letters or all lower case, the options to match are shown in brackets separated by the | character). Note that the . has to be un-escaped by adding a in front of it as it is the special character that denotes other characters.
When it finds a request that has passed all the conditions and matches the rule, it will rewrite the request with -, although this could just as easily go to a page on your site. Finally the [F] flag tells the server how to respond to the request, in this particular case, it will tell the browser that it is forbidden from retrieving that file.
作者: FIEND 時間: 2003-2-28 23:29 標題: 一個不可不知的模組 讚!!!!
Apache HTTP Server Version 1.3
Apache 1.3
URL重導指南
原著：
Ralf S. Engelschall <rse@apache.org>
1997年12月
本章是mod_rewrite參考說明文件的補充及使用指導，網站人員可參考這一章如何指導你利用Apache mod_rewrite來解決URL的常見問題，每一種用法都有例子跟隨。
Options ExecCGI FollowSymLinks Includes MultiViews
RewriteEngine on
# we are reached via /net.sw/ prefix
RewriteBase /net.sw/
# first we rewrite the root dir to
# the handling cgi script
RewriteRule ^$ netsw-home.cgi [L]
RewriteRule ^index.html$ netsw-home.cgi [L]
# strip out the subdirs when
# the browser requests us from perdir pages
RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
# and now break the rewriting for local files
RewriteRule ^netsw-home.cgi.* - [L]
RewriteRule ^netsw-changes.cgi.* - [L]
RewriteRule ^netsw-search.cgi.* - [L]
RewriteRule ^netsw-tree.cgi$ - [L]
RewriteRule ^netsw-about.html$ - [L]
RewriteRule ^netsw-img/.*$ - [L]
# anything else is a subdir which gets handled
# by another cgi script
RewriteRule !^netsw-lsdir.cgi.* - [C]
RewriteRule (.*) netsw-lsdir.cgi/$1
提示:
留意第四部份的L(last)旗標及代表不用更改的('-')符號
留意最後部份第一條規則的 ! (not)字元，及 C (chain) 鏈結符
留意最後一條規則代表全部更新的語法
以Apache的mod_imap取代NCSA的imagemap
描述:
很多人都想順利地把舊的NCSA伺服器遷至新的Apache伺服器，所以我們都想將舊的NCSA imagemap順利轉換到Apache的mod_imap，問題是imagemap已被很多超連結連繫著，但舊的imagemap是存儲在/cgi-bin/imagemap/path/to/page.map，而在Apache卻是放在/path/to/page.map。
方法:
我們只要將「/cgi-bin/」移除便可： RewriteEngine on
RewriteRule ^/cgi-bin/imagemap(.*) $1 [PT]
在多個目錄下搜尋網頁
描述:
MultiViews亦不能指示Apache在多個目錄裡搜尋網頁。
方法:
請參看以下指令。 RewriteEngine on
# first try to find it in custom/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]
# second try to find it in pub/...
# ...and if found stop and be happy:
RewriteCond /your/docroot/dir2/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir2/$1 [L]
# else go on for other Alias or ScriptAlias directives,
# etc.
RewriteRule ^(.+) - [PT]
保留舊有文件的URL
描述:
更改文件的副檔名後，如何讓舊的URL能對映到這新的文件。
方法:
把舊的URL用mod_rewrite重導至新的文件，若有正確的新文件就對映到這文件，沒有的話便對映到原有文件。 # backward compatibility ruleset for
# rewriting document.html to document.phtml
# when and only when document.phtml exists
# but no longer document.html
RewriteEngine on
RewriteBase /~quux/
# parse out basename, but remember the fact
RewriteRule ^(.*).html$ $1 [C,E=WasHTML:yes]
# rewrite to document.phtml if exists
RewriteCond %{REQUEST_FILENAME}.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# else reverse the previous basename cutout
RewriteCond %{ENV:WasHTML} ^yes$
RewriteRule ^(.*)$ $1.html
www0 IN A 1.2.3.1
www1 IN A 1.2.3.2
www2 IN A 1.2.3.3
www3 IN A 1.2.3.4
www4 IN A 1.2.3.5
www5 IN A 1.2.3.6
然後加上以下記錄：
www IN CNAME www0.foo.com.
IN CNAME www1.foo.com.
IN CNAME www2.foo.com.
IN CNAME www3.foo.com.
IN CNAME www4.foo.com.
IN CNAME www5.foo.com.
IN CNAME www6.foo.com.
$name = "www"; # the hostname base
$first = 1; # the first server (not 0 here, because 0 is myself)
$last = 5; # the last server in the round-robin
$domain = "foo.dom"; # the domainname
# speed up and secure processing
<Directory />
Options -FollowSymLinks -SymLinksIfOwnerMatch
AllowOverride None
</Directory>
# the status page for monitoring the reverse proxy
<Location /apache-rproxy-status>
SetHandler server-status
</Location>
# enable the URL rewriting engine
RewriteEngine on
RewriteLogLevel 0
# define a rewriting map with value-lists where
# mod_rewrite randomly chooses a particular value
RewriteMap server rnd:/path/to/apache-rproxy.conf-servers
# make sure the status page is handled locally
# and make sure no one uses our proxy except ourself
RewriteRule ^/apache-rproxy-status.* - [L]
RewriteRule ^(http|ftp)://.* - [F]
# now choose the possible servers for particular URL types
RewriteRule ^/(.*.(cgi|shtml))$ to://${server:dynamic}/$1 [S=1]
RewriteRule ^/(.*)$ to://${server:static}/$1
# and delegate the generated URL by passing it
# through the proxy module
RewriteRule ^to://([^/]+)/(.*) http://$1/$2 [E=SERVER:$1,P,L]
# and make really sure all other stuff is forbidden
# when it should survive the above rules...
RewriteRule .* - [F]
# enable the Proxy module without caching
ProxyRequests on
NoCache *
# list of backend servers which serve static
# pages (HTML files and Images, etc.)
static www1.foo.dom|www2.foo.dom|www3.foo.dom|www4.foo.dom
# list of backend servers which serve dynamically
# generated page (CGI programs or mod_perl scripts)
dynamic www5.foo.dom|www6.foo.dom
建立新的檔案型態及服務
描述:
你可在網上找到大量華麗的CGI程式，但又因這些CGI的艱難用法，很多人都不願意使用，甚至Apache Action Handler的MIME類型亦On the net there are a lot of nifty CGI programs. But their usage is usually boring, so a lot of webmaster don't use them. Even Apache's Action handler feature for MIME-types is only appropriate when the CGI programs don't need special URLs (actually PATH_INFO and QUERY_STRINGS) as their input. First, let us configure a new file type with extension .scgi (for secure CGI) which will be processed by the popular cgiwrap program. The problem here is that for instance we use a Homogeneous URL Layout (see above) a file inside the user homedirs has the URL /u/user/foo/bar.scgi. But cgiwrap needs the URL in the form /~user/foo/bar.scgi/. The following rule solves the problem: RewriteRule ^/[uge]/([^/]+)/.www/(.+).scgi(.*) ...
... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3 [NS,T=application/x-http-cgi]
Or assume we have some more nifty programs: wwwlog (which displays the access.log for a URL subtree and wwwidx (which runs Glimpse on a URL subtree). We have to provide the URL area to these programs so they know on which area they have to act on. But usually this ugly, because they are all the times still requested from that areas, i.e. typically we would run the swwidx program from within /u/user/foo/ via hyperlink to
/internal/cgi/user/swwidx?i=/u/user/foo/
which is ugly. Because we have to hard-code both the location of the area and the location of the CGI inside the hyperlink. When we have to reorganise or area, we spend a lot of time changing the various hyperlinks.
Solution:
The solution here is to provide a special new URL format which automatically leads to the proper CGI invocation. We configure the following: RewriteRule ^/([uge])/([^/]+)(/?.*)/* /internal/cgi/user/wwwidx?i=/$1/$2$3/
RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
Now the hyperlink to search at /u/user/foo/ reads only
HREF="*"
which internally gets automatically transformed to
/internal/cgi/user/wwwidx?i=/u/user/foo/
The same approach leads to an invocation for the access log CGI program when the hyperlink :log gets used.
From Static to Dynamic
Description:
How can we transform a static page foo.html into a dynamic variant foo.cgi in a seemless way, i.e. without notice by the browser/user.
Solution:
We just rewrite the URL to the CGI-script and force the correct MIME-type so it gets really run as a CGI-script. This way a request to /~quux/foo.html internally leads to the invokation of /~quux/foo.cgi. RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo.html$ foo.cgi [T=application/x-httpd-cgi]
On-the-fly Content-Regeneration
Description:
Here comes a really esoteric feature: Dynamically generated but statically served pages, i.e. pages should be delivered as pure static pages (read from the filesystem and just passed through), but they have to be generated dynamically by the webserver if missing. This way you can have CGI-generated pages which are statically served unless one (or a cronjob) removes the static contents. Then the contents gets refreshed.
Solution:
This is done via the following ruleset: RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^page.html$ page.cgi [T=application/x-httpd-cgi,L]
Here a request to page.html leads to a internal run of a corresponding page.cgi if page.html is still missing or has filesize null. The trick here is that page.cgi is a usual CGI script which (additionally to its STDOUT) writes its output to the file page.html. Once it was run, the server sends out the data of page.html. When the webmaster wants to force a refresh the contents, he just removes page.html (usually done by a cronjob).
Document With Autorefresh
Description:
Wouldn't it be nice while creating a complex webpage if the webbrowser would automatically refresh the page every time we write a new version from within our editor? Impossible?
Solution:
No! We just combine the MIME multipart feature, the webserver NPH feature and the URL manipulation power of mod_rewrite. First, we establish a new URL feature: Adding just :refresh to any URL causes this to be refreshed every time it gets updated on the filesystem. RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1
Now when we reference the URL
/u/foo/bar/page.html:refresh
this leads to the internal invocation of the URL
/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
The only missing part is the NPH-CGI script. Although one would usually say "left as an exercise to the reader" ;-) I will provide this, too.
##EOF##
Mass Virtual Hosting
Description:
The <VirtualHost> feature of Apache is nice and works great when you just have a few dozens virtual hosts. But when you are an ISP and have hundreds of virtual hosts to provide this feature is not the best choice.
Solution:
To provide this feature we map the remote webpage or even the complete remote webarea to our namespace by the use of the Proxy Throughput feature (flag [P]): ##
## vhost.map
##
www.vhost1.dom:80 /path/to/docroot/vhost1
www.vhost2.dom:80 /path/to/docroot/vhost2
:
www.vhostN.dom:80 /path/to/docroot/vhostN
##
## httpd.conf
##
:
# use the canonical hostname on redirects, etc.
UseCanonicalName on
:
# add the virtual host in front of the CLF-format
CustomLog /path/to/access_log "%{VHOST}e %h %l %u %t "%r" %>s %b"
:
# enable the rewriting engine in the main server
RewriteEngine on
# define two maps: one for fixing the URL and one which defines
# the available virtual hosts with their corresponding
# DocumentRoot.
RewriteMap lowercase int:tolower
RewriteMap vhost txt:/path/to/vhost.map
# Now do the actual virtual host mapping
# via a huge and complicated single rule:
#
# 1. make sure we don't map for common locations
RewriteCond %{REQUEST_URI} !^/commonurl1/.*
RewriteCond %{REQUEST_URI} !^/commonurl2/.*
:
RewriteCond %{REQUEST_URI} !^/commonurlN/.*
#
# 2. make sure we have a Host header, because
# currently our approach only supports
# virtual hosting through this header
RewriteCond %{HTTP_HOST} !^$
#
# 3. lowercase the hostname
RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
#
# 4. lookup this hostname in vhost.map and
# remember it only when it is a path
# (and not "NONE" from above)
RewriteCond ${vhost:%1} ^(/.*)$
#
# 5. finally we can map the URL to its docroot location
# and remember the virtual host for logging puposes
RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
:
Access Restriction
Blocking of Robots
Description:
How can we block a really annoying robot from retrieving pages of a specific webarea? A /robots.txt file containing entries of the "Robot Exclusion Protocol" is typically not enough to get rid of such a robot.
Solution:
We use a ruleset which forbids the URLs of the webarea /~quux/foo/arc/ (perhaps a very deep directory indexed area where the robot traversal would create big server load). We have to make sure that we forbid access only to the particular robot, i.e. just forbidding the host where the robot runs is not enough. This would block users from this host, too. We accomplish this by also matching the User-Agent HTTP header information. RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123.45.67.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
Blocked Inline-Images
Description:
Assume we have under http://www.quux-corp.de/~quux/ some pages with inlined GIF graphics. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. We don't like this practice because it adds useless traffic to our server.
Solution:
While we cannot 100% protect the images from inclusion, we can at least restrict the cases where the browser sends a HTTP Referer header. RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
RewriteRule .*.gif$ - [F]
Host Deny
Description:
How can we forbid a list of externally configured hosts from using our server?
Solution:
For Apache >= 1.3b6: RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F]
##
## hosts.deny
##
## ATTENTION! This is a map, not a list, even when we treat it as such.
## mod_rewrite parses it for key/value pairs, so at least a
## dummy value "-" must be present for each entry.
##
193.102.180.41 -
bsdti1.sdm.de -
192.76.162.40 -
URL-Restricted Proxy
Description:
How can we restrict the proxy to allow access to a configurable set of internet sites only? The site list is extracted from a prepared bookmarks file.
Solution:
We first have to make sure mod_rewrite is below(!) mod_proxy in the Configuration file when compiling the Apache webserver (or in the AddModule list of httpd.conf in the case of dynamically loaded modules), as it must get called _before_ mod_proxy.
For simplicity, we generate the site list as a textfile map (but see the mod_rewrite documentation for a conversion script to DBM format). A typical Netscape bookmarks file can be converted to a list of sites with a shell script like this:
We redirect the resulting output into a text file called goodsites.txt. It now looks similar to this:
www.apache.org OK
xml.apache.org OK
jakarta.apache.org OK
perl.apache.org OK
...
We reference this site file within the configuration for the VirtualHost which is responsible for serving as a proxy (often not port 80, but 81, 8080 or 8008).
<VirtualHost *:8008>
...
RewriteEngine On
# Either use the (plaintext) allow list from goodsites.txt
RewriteMap ProxyAllow txt:/usr/local/apache/conf/goodsites.txt
# Or, for faster access, convert it to a DBM database:
#RewriteMap ProxyAllow dbm:/usr/local/apache/conf/goodsites
# Match lowercased hostnames
RewriteMap lowercase int:tolower
# Here we go:
# 1) first lowercase the site name and strip off a :port suffix
RewriteCond ${lowercase:%{HTTP_HOST}} ^([^:]*).*$
# 2) next look it up in the map file.
# "%1" refers to the previous regex.
# If the result is "OK", proxy access is granted.
RewriteCond ${ProxyAllow:%1|DENY} !^OK$ [NC]
# 3) Disallow proxy requests if the site was _not_ tagged "OK":
RewriteRule ^proxy: - [F]
...
</VirtualHost>
Proxy Deny
Description:
How can we forbid a certain host or even a user of a special host from using the Apache proxy?
Solution:
We first have to make sure mod_rewrite is below(!) mod_proxy in the Configuration file when compiling the Apache webserver. This way it gets called _before_ mod_proxy. Then we configure the following for a host-dependend deny... RewriteCond %{REMOTE_HOST} ^badhost.mydomain.com$
RewriteRule !^http://[^/.].mydomain.com.* - [F]
Special Authentication Variant
Description:
Sometimes a very special authentication is needed, for instance a authentication which checks for a set of explicitly configured users. Only these should receive access and without explicit prompting (which would occur when using the Basic Auth via mod_access).
Solution:
We use a list of rewrite conditions to exclude all except our friends: RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp.com$
RewriteRule ^/~quux/only-for-friends/ - [F]
Referer-based Deflector
Description:
How can we program a flexible URL Deflector which acts on the "Referer" HTTP header and can be configured with as many referring pages as we like?
Solution:
Use the following really tricky ruleset... RewriteMap deflector txt:/path/to/deflector.map
This automatically redirects the request back to the referring page (when "-" is used as the value in the map) or to a specific URL (when an URL is specified in the map as the second argument).
Other
External Rewriting Engine
Description:
A FAQ: How can we solve the FOO/BAR/QUUX/etc. problem? There seems no solution by the use of mod_rewrite...
Solution:
Use an external rewrite map, i.e. a program which acts like a rewrite map. It is run once on startup of Apache receives the requested URLs on STDIN and has to put the resulting (usually rewritten) URL on STDOUT (same order!). RewriteEngine on
RewriteMap quux-map prg:/path/to/map.quux.pl
RewriteRule ^/~quux/(.*)$ /~quux/${quux-map:$1}
#!/path/to/perl
# disable buffered I/O which would lead
# to deadloops for the Apache server
$| = 1;
# read URLs one per line from stdin and
# generate substitution URL on stdout
while (<>) {
s|^foo/|bar/|;
print $_;
}
This is a demonstration-only example and just rewrites all URLs /~quux/foo/... to /~quux/bar/.... Actually you can program whatever you like. But notice that while such maps can be used also by an average user, only the system administrator can define it.
.+) /path/to/nph-xredirect.cgi/$1