After implementing any of the hotlink-prevention techniques described in our previous article, you may find it necessary to disable hotlink-protection for a specific directory. By default, htaccess rules apply to the directory in which it is located, as well as all subdirectories contained therein. There are (at least) three ways to enable selective hotlinking:

Place hotlink images in an alternate directory

This method works great if your hotlink-protection rules are located in a directory other than the site root. Simply create another directory outside of the directory containing the htaccess rules and place your hotlink-allowed images into that directory.

Create a pseudo-rewrite rule for the target directory

If your images are located within the influence of your hotlink-protection rules, and you need to enable hotlinking for a specific directory, it is possible to circumvent the anti-hotlink rewriting for that directory. In the htaccess file for the target directory, add the following, pseudo-rewrite rules ¹:

Continue Reading

When I wrote my article, Stupid htaccess Tricks, a couple of years ago, hotlink-protection via htaccess was becoming very popular. Many webmasters and bloggers were getting tired of wasting bandwidth on hotlinked resources, and therefore turned to the power of htaccess to protect their content. At that time, there were only a couple of different hotlink-protection methods available on the internet, and the functional difference between them was virtually insignificant. All that was necessary for up-and-coming bloggers-slash-site-administrators to eliminate leaking bandwidth and stolen resources was a relatively straightforward copy-&-paste procedure. Implementing the de facto htaccess hotlink protection code required a simple binary decision: “do you want hotlink-protection or not?”

These days, however, things are not so simple. Today, if you do a search on the internet for “htaccess hotlink protection”, you’ll get the phone book. There are countless mutations of the once tried-and-true htaccess code. There have been significant improvements, but there is also plenty of noise and error lurking among the countless techniques. These days, protecting your site’s assets and conserving bandwidth requires either trusting the first htaccess trick you find, or performing a mind-numbing and time-consuming amount of research to find the htaccess anti-hotlinking strategy that’s perfect for you and your domain. With this article, I do the grunt work for you — analyzing, deconstructing, and cannibalizing a contemporary collection of hotlink-protection methods to create the ultimate htaccess Anti-Hotlinking Strategy.

Continue Reading

In our previous article, we explain the process of allowing Feedburner to access your hotlink-protected images. The article details the entire process, which covers the basics of hotlink protection and involves adding several lines of code to your htaccess file. In this article, we skip the detailed explanations and present only the main points. The discussion is very similar for both Feedburner and Google Reader, and may be extrapolated to serve virtually any purpose.

If you are using htaccess to protect your images from hotlinking and have yet to check your feeds in Google Reader, you may be in for a little surprise. Unless you explicitly permit Google Reader access, your htaccess rules may be inadvertently preventing subscribers from viewing the images in your feeds. The same is true for Google Reader Mobile, which is probably far more popular than you may realize.

Continue Reading

Recently, we installed and configured the excellent WordPress Feedburner plugin by the venerable Steve Smith ¹. The plugin basically redirects our various WordPress-powered content feeds to Feedburner, which then delivers them to subscribers. This method enables us to take advantage of Feedburner’s excellent statistical tools. Further, all of the action happens silently, beneath the surface, and without the subscriber even realizing it.

After a few weeks running the plugin with great success, we began hearing reports of broken and missing images messing up our feeds. After some investigating, we realized that our tried-and-true anti-hotlinking htaccess rules were doing their job a little too well — blocking everyone outside our domain from accessing our image content — including Feedburner.

Continue Reading

There is a major problem with the “Hotlink Protection” feature of cPanel. To summarize the issue, allow me to quote a recent email sent to a completely unresponsive tech support department:

…The problem is that if I try to include any rewrite rules for permalinks, hotlinking, or blocking spambots, cPanel automatically enables its “Hotlink Protection” feature. And, even worse, it automatically adds every URL from every rewrite rule (even the ones for blocking spambots) to its “auto-discovered” list of URL’s for which image access is allowed. This means that every spammer that I am trying to block now has access to my images! If I try to remove the spammers directly from the “allow-image-access” list, the associated rewrite rules are automatically removed from my htaccess file, thus giving spammers full access to my entire site (instead of just access to images). So, it is indeed the case that I can’t add any rewrite rules to my site’s root htaccess file without cPanel automatically assuming that every URL on the page is related to hotlinking and subsequently adding them all to the “allow-image-access” list…

In other words, cPanel screws up htaccess rewrite rules via its “Hotlink Protection” feature. More specifically, spammers and robots that are denied site access via root-htaccess rewrite rules are automatically listed in the “allow access to images” field of the Hotlink Protection panel. Not good. Even worse, disabling Hotlink Protection automatically removes every rewrite rule from the htaccess file. Such bizarre functionality forces the user to choose between complete hotlink protection and other essential features such as pretty permalinks or spam blocking. Pretty sucky if you ask us. Nonetheless, here is a concise summary of the problem with the cPanel Hotlink Protection (cHP) feature:

Continue Reading