The Web has made incorporating material from other sources almost trivial: an anchor with the source attribute pointing to someone else's image and voila! your page looks much nicer already -
thanks to the hard work of that other person, or organization.
PHP-Nuke amplifies this tendency for "content sharing" with its easily programmed blocks: just include the output of another page in the $content variable, perhaps utilizing the output buffer -
and that's all, your block now shows the content of that page (see Section 20.2). Numerous blocks, such as Meteosat (Section
8.2.2), Sun & Moon (Section 8.2.1), Daily Comic Section 8.2.3), to name just a few, take advantage of this
technology. They inform, beautify and entertain you.
Or they make somebody very angry about you! This somebody is the original author who sees his content being used without permission and the bandwidth of his site used for purposes of other sites.
You should not underestimate these two problems:
-
Copyright: although a block that displays sattelite images for public use may be above suspicion, the situation becomes less favourable for a block that displays the work of other artists -
cartoonists, for example.
-
Bandwidth: because the image is still being called from the server of the author or his hosting account, the bandwidth or data transfer is tacked onto his account for each time that image is
loaded.
If you are the author of a collection of image files that you do not want to share through this so-called "hot" linking, there is a solution to your problem. It is not specific to PHP-Nuke, but it
is based on mod_rewrite (Section 25.2) and the .htaccess file (Section 25.4), so that if you are willing to deploy these two for a
search engine friendly PHP-Nuke (as shown in Section 25.5), then why not use them for a hot link stealth PHP-Nuke too? Even more so, since the
requirements from a programming standpoint are minimal.
 |
Find out if you have mod_rewrite installed first! |
| |
Be sure that your web server supports mod_rewrite (see Section 25.2 on how to find out).
|
Here is what you have to do in order to show an error to everybody who is trying to access an image on your server, but is not currently viewing a page of your domain:
Insert the following lines in the .htaccess file of the directory you want to protect:
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^$ 
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC] 
RewriteRule \.(gif|jpg)$ - [F] 
|
- Enable URL rewriting through mod_rewrite.
- Check that the HTTP referer of the client is not empty
- Check that the HTTP referer of the client does NOT start with your domain. Of course, you must enter your real domain here. The ! at the start of the condition pattern 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 respectively. Thus the pattern ^http:// would match strings starting in http://.
The sequence .* will match any character f or 0 or more times, and so adding it to the start or end of a particular string will allow fuzzy pattern matching. The ? will match zero or one occurences
of the string that precedes it, so (www\.)? means that either "www." appears once, or not at all. The [NC] flag at the end of the RewriteCond lines tells the server to ignore the case (no case) while
looking for matches.
- Finally, if all conditions are met, this rewrite rule matches anything that ends in .gif or .jpg. Note that the dot in front of the file ending is escaped in the regular expression (\.) and that
the OR function is indicated by the | . The dollar sign denotes the end of the URL. The [F] flag tells the browser that it is forbidden to retrieve that file.
 |
Will not work with faked HTTP_REFERER! |
| |
The method will also prevent web spiders from downloading your images. Web spiders are a popular tool and are used whenever a complete local copy of a site or resource is preferred over online
reading. Bear in mind, however, that good spiders allow the user to fake the HTTP referer field, thus presenting themselves as coming from some internal page of your domain. There is no way to force
a determined user to look at your pages or the advertisements you have there, before downloading your precious images.
|
Of course, you can just as well redirect the offending visitor to a file you have created just for this purpose, one that contains a standard text or image that reflects your feelings.
For this, you can change the above slightly to:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ http://www.mydomain.com/nasty.gif [R,L]
|
 |
Don't block search engine caches, image searches and automatic translations on your site! |
| |
The rewrite conditions we use here are a bit too restrictive: everything whose referer is not in our domain is blocked or redirected. But what about image searches with search engines? A search
engine will hot link our image when it shows it to the searcher. The same is true with the search engine cache and the automatic translations offered by Google or Altavista. You will not want to
block these services, let alone force search engines to display a nasty image in place of figures in a cached or translated document from your site.
Thus, unless you don't care, you will have to be more thoughtful and construct additional rewrite conditions that do not block useful services. For example, the following rules will allow the
Altavista and Google translation services to hot link images from your site:
RewriteCond %{HTTP_REFERER} !^http://jump.altavista.com/.*(www\.)?mydomain\.com.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://translate.google.com/.*(www\.)?mydomain\.com.*$ [NC]
|
|
See Using Mod_rewrite to block hot linked images, Preventing hot linking of images, Preventing Hotlinking with Apache mod_rewrite and
How to be a total prick using mod_rewrite.
