Htaccess problem


#1

I’ve been trying to enable some hotlink protection on my site. I only want people from 2 other sites to be able to even access the html or avi files within.

I tried the default link protection from the control panel as well as one generated by htaccesstools.com (which was basically the same), so it currently looks like this (obviously the real one has the real domains in it, and not stuff like ‘alloweddomain1.com’):
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?thedomainitself.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?alloweddomain1.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?alloweddomain2.com [NC]
RewriteRule .(jpg|jpeg|png|gif|avi|html|mov)$ - [NC,F,L]

With Firefox, it works perfectly. With IE (and I think Safari - have heard mixed responses), it will block the html page, but not the avi file. So if someone tries to access mydomain.com/index.html they get a forbidden error, but if they happen to the know the direct path to one of the avi files… they can still get them.

Anyone know why IE is doing this and how I can make it behave?


#2

It has to do with the HTTP_REFERER.

There is NO absoute way to guarente blocked content. Do not go into these htaccess editing thinking it’s going to work for all browsers or user set-ups, cause it won’t. The smart users will ALWAYS be able to get around your blockades only making you add more blockades making it even harder for your lagitamit users to gain access to your content. It’s a never ending loop. :wink:

Now, with that said … Not all browsers, especially IE will properly set the HTTP_REFERER header when requesting external objects like wave files, images, javascript files, etc. This is a problem with the browser, something you cannot fix.

You either have to just live with the fact there are methods around your “blocks” or just completely disable all blocks. Unforunately there isn’t really any other answer.

Just an fyi, this is why it works on occation when you think it shouldn’t: RewriteCond %{HTTP_REFERER} !^$

That condition permits any empty HTTP_REFERER value. Browsers that don’t properly set HTTP_REFERER will get past this. Users with proxies that clear out their HTTP_REFERER will get past this. Users that just type in the URL and hit enter will also get past this.


#3

I understand if someone really wants to get around things, they will. I’m not concerned about them, as that is futile.

I’m concerned with the average dumbass who posts a link in their blog with ‘hey look what you can download!’ and hotlinks to things on my site. It may not stop people, I just want to make it a little more difficult for them.

My ideal solution would be to say that only people who come from siteA or siteB would be given access to anything. To that end someone suggested a ‘GoodReferrer’ htaccess bit which said (again, obviously substituting real site names in there):
SetEnvIfNoCase Referer “^http://siteB.com/” GoodReferrer
SetEnvIfNoCase Referer “^http://siteA.com/” GoodReferrer
SetEnvIfNoCase Referer “^http://www.siteitself.com/” GoodReferrer
order deny,allow
deny from all
allow from env=GoodReferrer

Got mixed results - for me: Firefox worked, IE didn’t. For someone else: IE worked, Firefox was spotty. Although the majority so far seems to favor the first (IE not working).

I don’t necessarily need it to work for ALL, just MOST. :wink: I’d been using just password protection before, but the last hotlinker I caught just posted the username/password along with the links. How thoughtful of him.


#4

You’re definatly going to get spotty results with IE and that’s with the REFERER thing again; IE isn’t properly setting the HTTP_REFERER. Per the specs, ANY request must set that value, but it isn’t the case for IE. Then you compound that with MOST work based proxies will alter the HTTP_REFERER for any connection. REFERER is one of the most unreliable value to check against. It just doesn’t work “most” of the time.

If your pages are dynamically generated, you could use a seeded URL for the images. That’ll prevent hotlinking since the URLs will be constantly changing for them. Just base64 encode a URL with the date and some other data that will constnatly change. Unbase64 the URL and grab the bits you need and then “print” out your data from there.

ie:
http://www.domain.com/page.html
contains PNG: nohotlink/fkd92h9020f2=/image.png

nohotlink is a script hat will take the fkd92h9020f2= and decode it. Test is out with what you’d expect (today’s date, date hour time, whatever) and then if it’s valid open ‘image.png’, set content-type to text/png and print the image out.

Follow? it’s a method that most sites appear to be using these days since HTTP_REFERER is being more and more surcumvented by proxies.

If the pages aren’t dynamically created, just go with the RewriteRule from your initial post. There’s no way to fix IE and that’s your best bet w/out blocking lagitamit users.