Direct image access redirect, possible ?

[Sgt_Kickaxe]

This isn't a hotlinking or image display on other sites question.What If an href link leads directly to a url ending in .jpg I'd like a visitor to be redirected, to the home page for example.

I'm finding that a lot of my images have incoming links directly to the image and not to the page that has the image on it, thus the page url in the address bar ends in .jpg.

I'd like visitors to always land on .html for example, or always on my homepage if they access the image directly.

Concerns: breaking my own site when it makes image requests. Can it be done? Should it be done?

[Tashi]

Interesting question...

[lucy24]

It's really not any different from how you deal with hotlinking. You're just setting a kinder, gentler redirect at the end.

:: shuffling papers ::

If a vanilla anti-hotlinking rule looks like this

RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourownsite\.com(/.*)*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?otherexemptsite\.com(/.*)*$ [NC]
RewriteCond %{HTTP_REFERER} !^$

RewriteRule \.(jpe?g|JPE?G|gif|GIF|png|PNG)$ pictures/hotlink.png [L]

what you'd do is replace the redirect (mine, here, is a horribly garish image screaming NO HOTLINKS in painful colors) with a redirect to your home page. If you have different batches of images that you want to redirect to different pages, let us only hope that they live in different directories, or have names matching some pattern, so you can point everyone in the right direction with some speedy RegExes. And if not, this might be a good time to do some housekeeping in your /image directories ;-)

:: uneasily wondering what, if anything, [L] means ::

[Sgt_Kickaxe]

I see what you're getting at lucy24 but instead of doing a referer check and displaying anything I want anyone visiting any .jpg url on MY site directly to end up on the index page instead.

Ironically when you put hotlink protection in people tend to link directly to the image. Just like people rewrite non-www to www I want to rewrite all *.jpg to example.com (example).

ie: If you visit this url http://www.webmasterworld.com/gfx/logo.png you end up here http://www.webmasterworld.com/ instead.

I have a lot of incoming links pointing to non-indexable urls (.jpg) right now. Hmmm, I just created one for webmasterworld in that example too.

[edited by: tedster at 4:07 am (utc) on Apr 29, 2011]
[edit reason] un-hide the example URLs [/edit]

[lucy24]

instead of doing a referer check and displaying anything I want anyone visiting any .jpg url on MY site directly to end up on the index page instead.

You have to check for a referrer, because otherwise your site won't be able to display its own images. That's why you include the exemption for your own domain in any anti-hotlinking routine.

This is assuming your server speaks the same language as mine. (Some dialect of Apache. It's all Hungarian to me.) If some languages do distinguish between local <img src...> referers and clicked links, someone please tell me before I say something hopelessly stupid.

Ironically when you put hotlink protection in people tend to link directly to the image. Just like people rewrite non-www to www I want to rewrite all *.jpg to example.com (example).

Uh-oh, I think we're talking different languages. Human languages, I mean. To me, hotlinking is linking directly to the image.

If you visit this url [webmasterworld.com...] you end up here [webmasterworld.com...]
Uhm, no, I get the logo. Double-checked in another browser to make sure it wasn't pulling something out of my cache. Also happens if I put it as a link in a free-standing html file and open in yet a third browser.

[tedster]

To me, hotlinking is linking directly to the image

As I understand it, hot linking uses the <img> element's src attribute. I thought this question was about direct requests through an actual anchor element - an <a> element.

But even if that is what we're discussing, I don't know how the server can tell the difference, except by seeing a request for the HTML file just before the image request.

[TheMadScientist]

Lucy24 was close, I think ... Instead of an internal redirect to an alternate image, how about an external redirect to the home page?

I removed the .*, because 'followed by anything' is implicit if you remove the $, and why match (.* = anything except the end of a line) and/or store (() = grouping or store for back-reference) what you're not going to use?

RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourownsite\.com [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?otherexemptsite\.com [NC]
RewriteCond %{HTTP_REFERER} !^$

RewriteRule \.(jpe?g|gif|png)$ http://www.example.com/ [NC,L]

It could probably be shortened to:

RewriteCond %{HTTP_REFERER} !^http://(www\.)?(yourownsite|otherexemptsite)\.com [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|png)$ http://www.example.com/ [NC,L]

ADDED: You might be able to do something with serving your images via php to try and detect whether it's a direct access or an image request ... It would be really technical if it could be done (like possibly as far as creating a 'special log file', reading it and comparing IP Addresses and times of accessed html pages to IP Addresses and times of image requests) and I don't have time to sit and think about it right now, but I serve expires headers via php on servers that don't have mod_expires available and I think there might be a way, but whether there is any ROI or not, idk.

ADDED x 2: Maybe not ... Yeah, it's an 'intriguing' question and I keep wondering if you could, and idk about one image hotlinked but if there were 2 on the same page and images were served via php, that could be detected on the second request ... The requests would be too close together and the referrer would be the same 'external' site, so if two images were hotlinked on the same page, the second request could be detected relatively easily via php logging and image serving, but one? hmmm idk ... I keep running into 'doh, need javascript for that!' lol

[TheMadScientist]

Alright...

1.) Rewrite Image Requests to a PHP file via mod_rewrite.
2.) Check the referrer in the PHP file.

a.) If the referrer is allowed serve the image.
(It's more complicated than it sounds, because you have to set the headers for the image with php, and the actual location of the image can't be the same as the html request for the image or you get an infinite loop, but it can be done ... could be very simple: EG <img src="name.jpeg">; actual location is .jpg, rewrite .jpeg requests to a php file, then you can load .jpg files without issue via php (that's not exactly what I use, but it would work too) ... Might take an hour or two to get it working the first time, but it's good to know how to do, imo.)

b.) If the referrer is not allowed serve this:

<!DOCTYPE html>
<html lang="en">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Redirected</title>

<script type="text/javascript">
location.replace('http://www.example.com/');
</script>
</head>
<body></body>
</html>

You'll break a hotlinked image, because a browser won't execute a JS script (function) in an image call, but you're not serving the image either, so the hotlink breaks ... If the request is direct (only the image in the browser window) the browser will process the HTML of the page and the JS will kick in and redirect the visitor to the home page ... You may need to set full HTML headers via php to make sure you get cross-browser compliance, but it works in the version of FF I'm using.

...And don't ever ask a question I have to figure out like that again! lol

ADDED: Actually, the home page redirect will work too ... duh ... Now you have two ways to do it!
(That's what I get for not testing! lol ... [HeadShake])

ADDED x 2 [again]: Of course if you do it the PHP way you'll save bandwidth and resources if you're hotlinked often ... Might be a better, more efficient way of doing it, even though it's more complicated and tougher to set up.

[enigma1]

But even if that is what we're discussing, I don't know how the server can tell the difference, except by seeing a request for the HTML file just before the image request.

Yes it cannot tell the difference.

And the referrer reference is unreliable. What you could do is use an intermediate script to service the images. And images can be moved outside the web root. Like cold linking. Then you setup some temporary identifier with the script for each image that signifies a limited life span. So if the link is accessed again say after 1 hour will redirect to the home page. But certainly is not a good idea for SEs.

[TheMadScientist]

And the referrer reference is unreliable.

Not for visitors using standard modern browsers (most people) ... Yeah, sure they can be spoofed, and some people don't send them, but mostly the one's who would be spoofing are the people wanting to 'steal' the images via hotlinking, not the visitors who would be viewing the images ... The hotlinker has no control over the whether their visitor's browser sends a referrer header or not ... The only thing they could do is spoof the referrer and grab the image themselves, but the requests would show in the logs and could easily be blocked based on IP ... So, if you pay attention to your logs all you really miss with referrer is the people who don't send a referrer ... Why even worry about that tiny percentage of people? ... For the 'average' visitor, referrer is fairly reliable and much better than many of the alternatives, imo.

[lucy24]

And the referrer reference is unreliable.

But it only needs to be reliable in one direction: the referrer is either example.com, or it is not. If it is not, it doesn't matter whether it's another real site, a forged name, a cloaked name or a legitimate blank.

I've been making some assumptions.
#1 example.com doesn't itself contain clickable links to its own images ;-) So anything with example.com as referrer would be legitimate; you don't need to check a specific image against a specific page.
#2 There are no legitimate user-agents that send a blank referrer when requesting image files associated with the page you're currently on. If there are, you've got a problem.
#3 The images are not so enormously attractive-- and the surrounding text so unattractive-- that people will go to the trouble of forging example.com UAs just to get at the pictures without having to detour via the text.

But I think here it's just a matter of "I don't want people to look at my pictures without reading the text". Or possibly "without at least seeing the ads that keep me alive."

! New question that just occurred to me. What about people downloading images from within a page? Do you care? If so, how would one prevent it?

[TheMadScientist]

#2 There are no legitimate user-agents that send a blank referrer when requesting image files associated with the page you're currently on. If there are, you've got a problem.

Some people use 'anonymity' software, and some browsers may not in 'private browsing' modes (I haven't looked, because I really don't care to that level), but, as I said before, for most people in most cases referrer is fine.

If so, how would one prevent it?

That's really not completely preventable afaik ... The image is 'essentially downloaded' when it's requested ... It's sent to the client's browser on the client's machine to be displayed ... Streams are a bit different, but afaik, they're difficult to protect and easier than images.

[deadsea]

A word of caution. We redirected images to our home page and it had an unintended consequence. There were quite a few sites using our images. We were getting a significant number of hits to the images. We didn't consider that the images were easy to serve but the dynamic homepage would put additional load on our servers. When we put the redirect in place, it brought the server to its knees. The people that had <img src="ourimage"> were just showing broken images. We hosed our site rendering a page, and most of the time the user wasn't even seeing it.

[TheMadScientist]

Yeah, I thought of that after I realized option 1 worked too, but option 2 alleviates a huge amount of server load, because the php file that does the work is only 30 or 40 lines and the HTML served to break the hotlinks and redirect via JS is tiny too ... IMO most should be able to go with the JS option I posted relatively easily ... Not perfect and will miss some redirects, but you'll get most of them and break the hotlinks in the process.

I did miss the opening <head> and the <title> and other 'non-necessities' could be removed to save even more, but that much HTML is MUCH less than an image and the processing required for the rewrite and PHP is minute.

[TheMadScientist]

I guess you could actually just use an .htaccess redirect for unmatched referrers redirect the request to the html page I posted if you wanted ... I don't really have a hotlinking issue, because if you do it's generally an advertisement, so I don't think about solutions too often, but I think option 3 (this one) is probably what I would do.

Redirect to LIGHT html page (see above) ... The HTML is lighter than an image; breaks the hotlink; no php to parse or process; redirects most direct visitors to the home page ... I think it's a winner.

[enigma1]

There are no legitimate user-agents that send a blank referrer when requesting image files associated with the page you're currently on. If there are, you've got a problem.

addons.mozilla.org/en-us/firefox/addon/modify-headers/
I find it quite useful for privacy. There are also firewalls apart of other software than filter the referrer info. It's just too common and I do recommend hiding referrers for better privacy.

If someone wants to steal images he won't be bothered with hotlinking. That's different, if you're concerned about that deploy a watermark or similar mechanism on the images. Whatever is available from the web it can be retrieved in some way. Hotlinking can waste significant resources but redirecting to the home page is just amplifies it. I use thumbnails instead to reduce server b/w consumption.

And whoever hotilinks has lots of simple methods to auto display based on the image status.

<img src="http://example.com/image.jpg" onload="alert('image is hot-linked')" />

You can setup your own handler of course and improvise.

You may also want to add few exceptions like the site's icon which is also an image and won't carry a referrer.

[TheMadScientist]

Hotlinking can waste significant resources but redirecting to the home page is just amplifies it.

Did you not even look at what I posted?

[enigma1]

Worrying about no referrer is about like worrying about people with JavaScript off for privacy ... You miss all of them with your alert,

I don't follow, the example with the onload was placed so it's visible what the hot-linker can do. Use some DOM/js and is completely transparent. Someone who knows how to block js and alter headers on his browser, he would probably also know to fetch resources from within the domain only and so he won't even see the hotlinking nor access the external domain..

You also believe that because you output some html along with headers, the browser won't execute it, for which there are alternatives and will go through your js and execute the redirect to service the full home page. See if this code when placed on another domain pulls in the html and does a redirct and finally serves the full home page.

<iframe src="http://example.com/image.jpg" width="300" height="300"></iframe>

If I ever get into trouble with someone who hot-links and draws significant resources I have other methods to get around it, including cold-linking.

[TheMadScientist]

You also believe that because you output some html along with headers, the browser won't execute it.

Try it out ... I have.

JS Doesn't execute through an image call ... Hot link broken ... Correct, the iframe redirects to the home page if the image call is in an iframe, for which there are frame busters ... Standard installation on any of my sites ... Hotlink broken, frame busted and goal accomplished: Visitor is on my home page.

Really, we'll just have to agree to disagree on an approach ... If the JavaScript executes the visitor lands on the home page, right where I want them, and if it doesn't the image link is broken and the way I suggested breaks it with a VERY LIMITED amount of resources.

ADDED: I double checked in 2 different browsers ... If it's in an iFrame they land on the home page ... If it's in an <img> the hotlink breaks ... Basically, if I get the chance to fire the JS I can get the visitor to the home page, and if not, the hotlink is broken ... The only ones without a broken hotlink or landing on the home page are the people who don't send referrers ... No JS = Broken Image, so if they browse with it off, they don't get the image ... If they browse with it on and it fires they land on the home page ... The frame buster could probably be put in the little html file to break the frame first, and then redirect once the frame is broken, which could save even more resources if you don't allow caching.

[enigma1]

Hot link broken

Yes although the visitor won't see anything broken. He won't see the image

for which there are frame busters

But there are methods with frame busters busters to counter frame busters (204 header?).

We can go in circles here but I will try to concentrate on the least expensive resource methods but also reliable. Apart of the fact anyone could modify the referrer another reason I don't trust cross-referencing the referrer is because of SEO.

I don't know all the details but I have seen SEs doing visits on pages with hidden UAs and blank referrers. SEs do index pages with image extensions (you can check google inurl:.jpg) and they have the html on index from the .jpg. I don't know what duplicated content this may cause. It's just too risky. You now have to go in and add exceptions for search engines if you can detect them.

[deadsea]

Javascript executes in images using the new .svg image format. You might be able to craft an svg image that detects whether it is part of a larger page or not and acts accordingly.

[TheMadScientist]

I'll put it all in one post:

I don't know all the details but I have seen SEs doing visits on pages with hidden UAs and blank referrers.

Search engines don't send referrers, that's one of the reasons you check to see if it's blank with the mod_rewrite.

Yes although the visitor won't see anything broken.

The point is they don't see the image, and in some browsers it will show the little 'broke image' symbol, in others, it just doesn't show.

But there are methods with frame busters busters to counter frame busters (204 header?).

SMH ... At some point in time (a while ago) you went way beyond the point of diminishing returns to try every single solution ... The 'perfect' solution is to not put your images on the Internet, other than that, you pretty much have to settle for reasonable.

Apart of the fact anyone could modify the referrer...

Yes, any person with a browser can theoretically modify the headers the browser sends, but it's completely beyond the time and effort most Internet users are willing to put in. My site CANNOT modify the headers YOUR browser sends, unless I hack the browser, which again is way beyond the point of diminishing returns to even care about, imo, because the likelihood of that happening is so small, imo, they can have the *bleeping* image if they want it bad enough to hack a browser to show the image to their visitors.

...another reason I don't trust cross-referencing the referrer is because of SEO.

See Above ... I CANNOT modify the information YOUR browser sends, unless I hack it ... YOU can, but MOST people who use browsers couldn't careless what headers their browser sends or doesn't send as long as it works.

I don't know what duplicated content this may cause.

None...

It's just too risky.

Then don't use it, but don't let your lack of understanding and fear be the guiding force for others.

You now have to go in and add exceptions for search engines if you can detect them.

They don't send referrer headers, that's already been covered by the mod_rewrite.

I'm done now ... I'll let readers decide if they want to try and pick up what's probably (my guess) the low single digit % of misses not covered by the below.


# Mod_Rewrite below
RewriteEngine on
# If the referrer is NOT your site or allowed sites (below)
RewriteCond %{HTTP_REFERER} !^http://(www\.)?(yourownsite|otherexemptsite)\.com [NC]
# If the referrer is NOT empty (below)
RewriteCond %{HTTP_REFERER} !^$
# If the requested file name ends in .jgp, .jpeg, .gif, .png
# And the preceding conditions are true serve the .php file
# in place of the image.
RewriteRule \.(jpe?g|gif|png)$ http://www.example.com/the-php-file.php [NC,L]


the-php-file.php

<!DOCTYPE html>
<meta http-equiv="window-target" content="_top">
<title>Redirected</title>

<script type="text/javascript">
if(top != self) top.location.replace(location);
else { location.replace('http://www.example.com/'); }
</script>
</head>
<body>
<a href="http://www.exmaple.com/" target="_top">This is a hotlinked image click to visit the site and see the image.</a>
</body>
</html>

[enigma1]

The 'perfect' solution is to not put your images on the Internet

Exactly a way I recommended from my first post was cold-linking where you don't have the originals exposed because they are behind the web-root of a domain or use a watermark.

Then don't use it, but don't let your lack of understanding and fear be the guiding force for others.

yes well you don't explain much about this. Your various images may end up as pages having the same content.

You say there is not risk but is quite possible. If someone exposes your images as links now SEs will follow, your htaccess will now invoke the the-php-file.php which in turn will return html code with a 200 OK. Different urls serving the same HTML code. That's duplicate content.

[TheMadScientist]

If someone exposes your images as links now SEs will follow, your htaccess will now invoke the the-php-file.php which in turn will return html code with a 200 OK.

Do you really not get the fact search engines don't send referrer headers so they won't be served the .php file? They will always get the image when they request the image, because they don't send a referrer header; the referrer is blank from search engines!

Test it.

add: <meta name="robots" content="noindex,nofollow"> to the file if you're concerned about it being found.

Really, you just don't understand what you're talking about very well ... Search engines are covered ... The link other people put on their site will be to the image ... If they link to the .php file there's no hot link, and there's a good chance any frame they have it in is broken and visitors are redirected IOW: People will not be linking to it ... It's NOT the file you want to run into as a hotlinker; you just don't want anything to do with that php file ... If search engines follow the image call they will find the image, because they don't send referrer headers ... If they find the file, put a robots tag on it, or server an X-Robots header with the php and they won't care.

Duplicate content within your own site doesn't matter anyway ... They want you to let them find it so they can figure out which version, if any, to show ... They do not 'penalize' you for it, they try to figure out which version to show, so it's better to not have it, and when it's a real page then you'll have split link weight if people (or you within your site) link to two different versions of it, but a 'nothing' page like this will be treated as that if they find it, nothing...

[enigma1]

Maybe I don't understand it very well. Just to be sure, are you saying if the referrer is empty/blank you will serve the real image?

RewriteCond %{HTTP_REFERER} !^$

?

[TheMadScientist]

Yes, absolutely ... That's what that line does.

It makes sure bots and others who don't send referrer headers anywhere are served the image, otherwise it could break on your site, but the main 'visitors' who don't send referrer headers are bots, not people. For a person to NOT send a referrer header, usually they have to WORK to keep it from being sent, which is not something most people care to do.

You have to change the line before to your site too, so it would be something like this:

RewriteCond %{HTTP_REFERER} !^(www\.)?yoursite\.com [NC]

The (www\.)? means if the referrer (it's supposed to be spelled wrong above) is yoursite.com OR www.yoursite.com to serve the real image too.

They're written 'backward' so the 'redirect' happens if they are NOT true.

IOW they say: If the referrer IS empty OR IS yoursite.com OR IS www.yoursite.com to 'not do anything special' and serve the image. If referrer IS NOT empty, and it IS NOT yoursite.com and it IS NOT www.yoursite.com, then we don't want to show the visitor the image, because we KNOW they are a 'person visitor' and requesting it from another site, so we want to break the hot link and try to get them to the home page of your site ... That's what that little php file does.

[lucy24]

For a person to NOT send a referrer header, usually they have to WORK to keep it from being sent, which is not something most people care to do.

Or they like the picture so much that they've got it separately bookmarked, or they've memorized the address and type it into the address bar "cold". (When I originally wrote my hotlink routine,* I wasn't even thinking of robots, just one-offs. That's why blank UAs are permitted. File under: No Skin Off My Nose.)

Still with us, Sgt_Kickaxe? I think the bottom line is that there's no way to distinguish between hotlinks and direct visits, so there's no way to send the requests along different paths, which is what you originally asked about.

You could pore over your logs-- or, more sensibly, run up a simple program to do the work-- and see if you're getting multiple requests for a particular image from the same outside location. Then investigate those locations and take individual action. But that's only worth the effort if it's a small number of culprits.

If you've got a whole lot of images that you don't want people to swipe, you may have to go the "watermark" route.


* Or, in my case, got it from someone else, hence the "I don't know what this means, so I'll just copy it as-is" elements. I have now grasped that $ doesn't mean "string", it means "end of this regex line". For reasons 2C2E I never used it, so it never got internalized like its counterpart ^.

[TheMadScientist]

Uh, you could edit the mod_rewrite to the following:

# Mod_Rewrite below
RewriteEngine on
# If the referrer is NOT your site or allowed sites (below)
RewriteCond %{HTTP_REFERER} !^http://(www\.)?(yourownsite|otherexemptsite)\.com [NC]
# If the visitor is NOT GoogleBot, Slurp, BingBot (below)
RewriteCond %{HTTP_USER_AGENT} !googlebot|slurp|bingbot [NC]
# If the requested file name ends in .jgp, .jpeg, .gif, .png
# And the preceding conditions are true serve the .php file
# in place of the image.
RewriteRule \.(jpe?g|gif|png)$ http://www.example.com/the-php-file.php [NC,L]

Keep in mind, you would break the images for users surfing your site without sending a referrer but if you detected an empty referrer with PHP (on the actual pages, not the mini-page above) and detected the user-agent was NOT GoogleBot, Slurp or BingBot (again on the actual pages, not the mini-page above) you could leave a 'dynamic note' on the pages letting users know they need to adjust their browser or software settings to send referrer information to view the images on the page...

So, if you don't mind breaking the images on your site (and quite probably redirecting them to the home page) for the few people who surf with no referrer information, unless they turn it back on, yes, it can be done with a combination of JavaScript, PHP and Mod_Rewrite.

You would NOT break the images for bookmark clicks or type-ins for the actual pages for people sending referrer information either, because their browser would send the page as the referrer for the image request ... Direct 'image only' requests would be broken and likely redirected, and the same would happen for users surfing without sending referrer information, but for most people, most of the time, imo, it's a solution that might work.

[lucy24]

You would NOT break the images for bookmark clicks or type-ins for the actual pages for people sending referrer information either, because their browser would send the page as the referrer for the image request ...

I meant people going directly to the image. I actually have a couple of those among my bookmarks.

[Sgt_Kickaxe]

I meant people going directly to the image. I actually have a couple of those among my bookmarks.

I respect that you want to bookmark my image but you're passing pagerank to a .jpg url instead of to the page it's on and I'd REALLY appreciate it if you simply linked to the page it's on instead.

The code I'm looking for would do just that. You click on your bookmark to my image url but my server says oops, that's a direct to image link, 301 to the page it's on instead.

I left figuring out which page it's on out of the discussion since that's another can of worms. Thanks for the code examples Mad, i'm still trying to test it and get real logs to see what(if any) the impact on server is.

I know of an image gallery that has tens of thousands of links pointing directly to images, he's been offering the link code people use to copy/paste a link with, and if he could pass a small amount of the pagerank that's surely sent his was to a real page... yikes.