jdMorgan - 4:55 pm on Jan 16, 2009 (gmt 0)

It is not an issue of users "messing with their referrer" -- In most cases, people whose referrers get "messed" have no idea that it is happening. The OP states that he knows how to do "regular anti-hotlinking" so the implication is that those methods are not adequate in this case.

All referrer-based methods have a big hole in them, because blank referrers must be allowed so that your site does not look broken to people who type in your address, use a bookmark, use an ISP which uses in-network caching proxies to reduce out-of-network traffic (such as all AOL and Earthlink subscribers), or who are using "internet security" software which blocks the Referer header -- either with or without the user's knowledge. If JavaScript is used to load images on your site, then IE won't send a referrer when doing so either. So blank referrers must be allowed unless you want your own site to look broken to these users.

At the same time, some portion of users --the ones whose referrers are blocked-- will bypass your anti-hotlinking measures, and they will see the hotlinked images on the other site's pages.

Referrer-based anti-hotlinking with blank referrers allowed is therefore only a "usually good enough" solution, in that people who do not site behind caching proxies or use internet security software which blocks the referrer will see broken images on the hotlinking sites. Some of them will complain via e-mail or by posting comments in blogs or on forums. This represents a "hassle" to the hotlinking site's Webmaster, which is often enough to get him to quit hotlinking.

In cases where the hotlinking webmaster is not paying attention or his users don't complain, then 'creative' solutions can be used, such as serving an alternate image. Some webmasters like to get tricky and serve 'objectionable' images, impugning the hotlinking site's reputation. Others like to serve an image with an embedded (image) link to their own site, so as to possibly recover some traffic in exchange for the bandwidth otherwise wasted on serving the hotlinked images.

But the bottom line is that referrer-based anti-hotlinking solutions are only partially-effective because blank referrers must be allowed. So for more obstinate cases, the image-serving-script-and-cookie method is called for, as I stated in my first post and echoed by later posters.

I should probably add that when testing anti-hotlinking code or any server-side access-control-code, it's important to completely flush your browser cache between tests, or to temporarily disable it by setting the cache size or cache expiry time to zero. Otherwise your browser will cache the image (or the 403-Denied response) and serve it to you from cache on subsequent requests without sending any request to your server. Since no request is sent to the server, your server-side access-control code won't have any effect, confusing your test results.

Jim