Request for hotlink protection

[digitex]

I hope everyone had a good holiday.

My webhost has a cool feature called hotlink protection which prevents outside sources from linking directly to an image on my site using an < img > tag and therefore stealing bandwidth. However yesterday I found a German site with one of my images on it hotlinked to my site and so I contacted my host and was told that since my site was installed using a web app (processwire) and the image references are made through database entries that their hotlink protection won't work.

I searched the forum here for something similar for pw and found nothing. Is there a way (module or htaccess command) to protect images from being hotlinked? If so, could someone point me to it?

If not, is there the possibility for this? There's a few photographers using pw in the showcase section and I'm sure they would appreciate the ability to prevent this kind of thing. It's no protection from copyright infringement as anyone could save the image to their HD and upload to their own server but it at least might prevent bandwidth from being siphoned off.

[Joss]

Hi Digitex

Can't you just do it through your htaccess file - basically, set it up so that files that end with jpg, png and so on can only be referred directly from your own site.

See here:

http://net.tutsplus.com/tutorials/other/5-fun-and-practical-htaccess-solutions/

(I haven't tried this, by the way)

[digitex]

Hi Joss.

It should work but that's how the webhost's built-in thing is supposed to work and it didn't. The htaccess rule in the link you provided is the same as the one the webhost's app inserts so it probably needs to be composed specifically for the way a CMF like processwire handles requests. I don't know enough about it to figure out how to do it.

I figured a module, by someone much better at this than me, with fields to specify which file extensions to include and which domains to allow, that would insert the rule into the htaccess file in a pw friendly way, might be the ticket.

[Joss]

Ah, that is a pity.

Somewhere there is a wordpress addon that does this for Wordpress.

If you can track that down, there may be some clues in there - see how they achieve it.

Joss

[Soma]

Theres nothing special about how pw handles file requests so you should be able to add the rules to the htaccess of pw.

[digitex]

Theres nothing special about how pw handles file requests so you should be able to add the rules to the htaccess of pw.

The webhost wasn't specific beyond what I mentioned in the OP. They weren't picking on processwire or anything they just said "As your domain is installed with a web application, the hotlink protection will not work as in normal cases. This is because the references to the images are made through database entries and most of the images are embedded in the site template" their words not mine. I leave room for the possibility the tech support people have no idea what they're doing and the problem is somewhere else completely.

It could be as simple as the order of the rewriterules. Since pw installs an htaccess file any additional rules would get tacked on after the pw entries. If I add the hotlink blocking back in manually and place it right after rewriteengine on it might work. Whatever the problem is I'd like to fix it. I will edit the htaccess manually and see what happens but i still think a simple module that will insert the proper rewriterule in the proper place would be great as it would keep people from having to muck about with the htaccess manually.

I'll report back if changing the order of the rules helps.

[Soma]

That response doesn't make much sense me, but I don't know what their protection is. Images are physical and there's nothing more special about it, than if you'd put a static html with an image that lives in a folder somewhere.

Adding this to after the "RewriteEngine on" in the PW .htaccess will protected any image request that does not come from the domain specified. Works well.

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.ch [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

[Joss]

That is what I thought - but then, I always get this sort of thing wrong.

In the end, the fact that the page is being produced dynamically is neither here nor there - it is what is being requested that is important, and that is just a link to a particular file or file type with an address to the directory in which it is stored.

Yet another support chappy that knows even less than I do? I always find that upsetting!

[digitex]

Maybe. Maybe not. It still don't work.

I've tried several different approaches. I have two domains with this webhost personally, one is just static html (until I get to it and re-do it) and the other is pw. The same hotlink block works for the static site but I can not get it to do a thing on the pw site. I don't doubt the tech may not be an expert but if it don't work it speaks for itself.

Soma, are you currently using this particular rule in htaccess on a pw site and it works or are you just saying it should work?

FYI you don't need jpg|jpeg just adding jpe?g does the trick.

[Soma]

It works fine here (tested). The request of an image from another domain is blocked. If pw is installef or not doesnt matter. The request doesnt get processed by pw in any way only the htaccess gets into play.

[digitex]

It works fine here (tested). The request of an image from another domain is blocked. If pw is installef or not doesnt matter. The request doesnt get processed by pw in any way only the htaccess gets into play.

Well that is interesting. I just did a test of my own. I uploaded a jpg to the root directory of my server (outside the site directory). Created a test.html doc and added in a hotlink to that image and uploaded that doc to my other, unrelated domain. Blocked. No problem. Works like a charm. Did the same thing with an image within pw and the image loads. Not blocked. It does not work.

[Soma]

Hm and where in the htaccess have you added the rules exactly?

[digitex]

Sorry. I had company for dinner so had to break to make it.

I added the rule directly below RewriteEngine on. It did nothing so I tried setting the rewrite base just to see what happened and moved the rule to below that. That didn't do anything either.

[Joss]

This may be a directory problem - in other words it is only working in the root directory, it needs to override all?

[digitex]

This may be a directory problem - in other words it is only working in the root directory, it needs to override all?

An htaccess file effects the directory it sits in and all it's sub-directories so since I have only one htaccess and it's in the root, It should effect everything. Plus, all the rest of the rules in that file are for pw and they all work as normal.

[digitex]

I did some more testing with the image I uploaded to the root, via FTP rather than through pw. I moved it progressively down into the nested folders, first site > assets > files > to finally 1056 and tested the hotlink block each time and it worked each time. And yet, the image that was already there, uploaded via the admin interface loads when hotlinked.

I don't understand everything in that htaccess file, is there maybe something else in there that might override the blocking rule for images uploaded through or contained within pw?

[Soma]

If you put the Rules right after the "RewriteEngine on", there's nothing else that would make it not work and PW rules afterwards won't get executed at all obviously.

I can't think of anything why it shouldn't work. Maybe something on your host is configured differently. Could it be that files with two "." in the filename are a problem for you?

[digitex]

That's a good thought. I made the same test on a different pw website using a different host and it seems to work. I don't know why it won't on this one but when all other options are run out then the only thing left is the host. I doubt I'll get anywhere with them since they already told me it won't work so short term I deleted the image that was being hotlinked and long term I may look at new hosts.

Thanks Joss and Soma for tackling this with me.