Forum Moderators: phranque
I use frontpage to publish... and created the existing code in notepad... with the dot before the htaccess
There's lots of prior threads with example code, as well as many warnings about which methods are ineffective.
What have you tried so far?
"mysite" = to my website domain
Make sure you are not fooling yourself while testing; Completely-flush (delete) your browser cache between each test.
The code can be slightly-improved for correctness and performance, but without any functional changes:
RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteRule \.(jpe?g¦png¦gif)$ - [NC,F]
Do be honest I don't think the when I publish this htaccess file is being published...
Now what...
Do be honest I don't think the when I publish this htaccess file is being published...
It's probably just hidden. Display depends upon the FTP client that you are using. I keep my files as htaccess.txt - then upload, delete the .htaccess and rename the file that I just uploaded.
I use WS_FTP Pro usually and the setting for the Remote Filter Mask needs to be set to -a
With a portable version of Filezilla, which I sometimes use from a pocket drive, you need only show hidden files.
Dig into the settings, and if you find a check-box for "Show system files" then tick it. Alternatively, you may find a setting for "Directory listing command." In that case, the "list command" should be "ls -al" in order to show .htaccess, .htpasswd, and other system files.
If you are using FrontPage Extensions on your Apache server, be very careful not to overwrite the changes that FrontPage makes to your .htaccess files, and be very careful that FrontPage doesn't overwrite your manual .htaccess changes either. It is notorious for overwriting the "Options +FollowSymLinks" setting that mod_rewrite requires.
Jim
I don't understand... when you say upload then upload again... do you mean publish or upload somewhere else?
I created the htaccess in notepad... dropped into my directory as htaccess.txt then changed the file to name to .htaccess and added the code... and saved... I can see the file in my directory but when I open FrontPage it is NOT there... so I don't think it is being publish to my server...
Totally and utterly confused... all I know is that I have about 102 hotlinked images stealing my bandwidth... according to my AWA stats and I can't seem to fix the problem with htaccess...
I created the htaccess in notepad
Good so far.
.....................
dropped into my directory as htaccess.txt then changed the file to name to .htaccess
Still in good shape, though I don't overwrite. I delete the existing .htaccess first.
.....................
I can see the file in my directory
Still good. Wouldn't hurt to move a copy of this from the server to a folder on your machine and double check that the .htaccess on your server is in fact the new version. No reason it shouldn't be, but no harm in a quick check. Then delete.
.....................
so I don't think it is being publish to my server...
Another reason to pull a copy from the server and make sure that you have properly uploaded the new version.
.....................
Totally and utterly confused... all I know is that I have about 102 hotlinked images stealing my bandwidth... according to my AWA stats and I can't seem to fix the problem with htaccess...
Easy. Relax. You'll get it. It will be fine. Getting it done this very second or tomorrow isn't going to make much difference. You're upset, but this is very fixable.
.....................
If all of the above are okay, then there is a problem with the directives. Post your .htaccess - or at least the relevant portions and maybe that will allow an error to be found. .htaccess, like most dot files is a potent tool, but the slightest error and all kinds of things can go wrong. I've seen whole websites blown up with a single typ0.
.....................
Can't tell you the first thing about FrontPage, though there is no 'current version'. It was finally dumped a couple of years ago for Microsoft Expression Web and Sharepoint Designer. I think Sharepoint is more corporate and server oriented, and Expression Web closer to a FrontPage replacement for the average FrontPage user.
there is already an .htacces file there but does not have the hotlink code
I wondered about that. I am NOT an .htaccess expert so you may get differing options as to how to proceed. Don't be in a rush to take my 'advice'. Best advice is to not be in a rush at all and get some consensus. The water is a bit deep right now. Bandwidth is cheap. You can afford another day or two.
................
could that be the problem
It absolutely is. The question now is solution.
................
You can have multiple .htaccess files. Limit one per directory, and if there is conflict, sub-directories override higher level directories. However, few people actually need an .htaccess file anywhere other than root / (Might actually be workable for you (though advisable is another issue), if all your images are in their own sub-directory(ies). It is also more complicated to get correct than what you are trying to do now, so would recommend proceeding with caution.
................
Priority #1 - Make sure to stash a copy of your original (or current) .htaccess locally so that if you blow something up you've got a 'clean' file to put back in place. This is in addition to the new file. Clean copies of both should be backed-up and locked up.
................
Priority #2 - Why is the hotlink code not in the .htaccess file that you have now confirmed has not been updated/replaced.
1) It wasn't deleted to start with. Since you checked, and it's there, we know this to be true.
2) It wasn't overridden if not deleted. You thought that you replaced the file, but in checking the file have confirmed that that is not the case. Why - I can't say for sure. Most FTP clients will provide a 'prompt' warning in overwrite situations. What FTP client are you using?
3) The uploaded file is not where you think it is or where it belongs.?
................
can I add the hotlink code to the existing one... which I don't want to do
Why not? Presumably you need/want the directives that are in the current file. You are merely adding to that file new directives to deal with the hotlinking.
................
and mess up my files...
That is why one backs-up everything - always. Especially mission critical files. Except for simpleton updates, I copy a file before I mess with it. That's any file, any document. Unless it is minor stuff, only fools work with original documents with no back-up or copy.
................
The issue seems to be why you are not putting the new file on the server when you think that you are (or not putting it in the correct location).
I am aware that I am not answering the question but asking several more - but this is a troubleshooting situation now and there are several possibilities and I am confused as to where the wrong turn is at.
1) If you can see the file, you can delete the file. If you can delete the file, you can replace with the new file.
2) The FTP question keeps coming back round for me on this and seems a likely weak link. My first guess it that you think you are publishing this file, but not really doing so.
4) Not familiar with Plesk, but you can probably upload this file right from a control panel. I don't use them, they tend to be crude for my needs, but it's only one file.
5) Depending upon the host, the may even have an automatic 'one-click' option to ban hotlinking. A lot of inexpensive hosts have that kind of one-click feature. If so, and if you use it, beware that it could overwrite/replace your current file and not simply add to the file. I've seen this happen, though don't know how prevalent it is. With few exceptions, file transfers are all WS_FTP Pro my purposes.
Using FTP, download the existing file from your server. Make a dated *copy* for backup. Add your anti-hotlink code, then upload the resulting file to your server.
FTP is a file-transfer tool. That's all it does, and it's pretty much completely-manual. As a result it won't get in your way, but it also wont' stop you from doing something "wrong" like deleting a critical file.
There are many excellent and free FTP clients, Filezilla from Sourceforge (as previously-mentioned by D_Blackwell) and Leech FTP come to mind. You can even use Internet Explorer's "FTP View" if you don't want to install a new client -- but I find that it "hangs" quite often because it doesn't have robust timeout handling.
Jim
There are some really old threads at Webmaster World which provide confusing insights into use of htaccess with FP [google.com] and/or FP's "publish" option.
As I recall, the effective explanation was to edit the "published" htaccess (adding in additional lines) without changing any of the existing htaccess lines created by FP during the process of "publish."
There are some forums across the internet that deal exclusively with FP that would provide a more effective insight.
I used FP early on, however I never used the "publish option" and basically utilized FP as an html editor. Neither did I utilize FP Extensions.
Just one final question will this htaccess code remove existing hotlinked images or only the ones that try after I uploaded the file...
thanks again for all your help... although I did not know how to do it myself at least I learned what htaccess files can and cannot do...
.....please can someone offer me a htaccess code that will stop hotlinkers dead.....
Bear in mind that you asked to stop hotlinking. IF your images are that popular, THEN they will simply be lifted and served directly in most cases. (Or, in a more slightly more sophisticated effort, lifted to another server/domain and served from there to the destination site.)
ElvisFan and jdMorgan provided directives that will stop hotlinking - not image theft. Have you thought through to the next logical problem?
.....................
will this htaccess code remove existing hotlinked images or only the ones that try after I uploaded the file...
It won't 'remove' anything except the ability to serve images from your site directly to another site. It will apply to all images that meet the parameters. I believe this is, in part, why jdMorgan made one of his minor changes regarding .jpe .jpg .jpeg - But jdMorgan can explain each step and portion of that RewriteRule line better than I can.
.....................
If you have a lot of images being hotlinked, and from multiple sources, and they suddenly disappear - maybe the other sites' will take somebody else's - but maybe they will just lift yours out and continue to use them anyway. Expect to get ripped. Odds? 98%+
Someone puts a link to your image on their Web page.
A visitor (innocent of any participation in the hotlinking) loads that page from the other site.
That visitor's browser loads the image from your server.
What anti-hotlinking code does:
The code blocks browser requests which include an HTTP Referer header indicating that the referrer (the page containing the <img src=""> tag) was *not* on your own site. This results in the visitor seeing a 'broken image' icon on the page of the hotlinking site. He thinks that site is broken (remember, he's totally unaware that his browser tried to fetch the image from your site and not from the site he was visiting).
This visitor may or may not report the broken image to the hotlinking site's Webmaster.
How this can go wrong:
Some users install and use 'internet security' software or plug-ins which block the sending of the HTTP Referer header. In this case (and the following), your server will see HTTP Referer header as blank.
Some ISPs use caching proxies to reduce the traffic in and out of their own networks. Requests from these caching proxies will not carry an HTTP Referer header. Typically, their customers are totally unaware that this is happening. Examples of such ISPs are AOL and EarthLink.
If an image request is the result of a JavaScript image load, then it will carry no HTTP Referer header. Similarly 'media players' do not typically send Referer headers.
So, if the HTTP Referer header is blank, there is then no way for your server to know if this request was referred from your own site or from another site. If you block image requests having blank Referer headers, you will then make your own site look broken to some of your own visitors.
Client-side (e.g. browser) caching plays an interesting role here: If a visitor has previously-loaded your image, then he will continue to see your image on the hotlinking site's page until that entry in his browser cache has expired or has been replaced by more-recently cached objects (the browser cache is of a fixed size, and cache entries are typically overwritten in an oldest-entry-replaced-first manner.)
One interesting aspect of this is that if a new visitor to the hotlinking site sees a broken image as a result of your anti-hotlinking code and reports that problem to the hotlinking Webmaster, the Webmaster may not see that the image is broken, because his browser may have a cached copy of that image. He may think his visitor has a problem instead, and dismiss the error report. You could call this confusion and wasted time for the hotlinking Webmaster "justice." It's also sometimes fun to watch forum members argue about whether an image is 'there' or not in their own forum.
In such cases, it may be beneficial to serve an alternate image (say one containing a link to your own site) instead of simply denying the request. However, for efficiency, it's often best to simply deny these requests and go on with more-profitable projects. However, some warnings are in order:
Do not replace your image with something "nasty." This is "bad citizenship" as best, and may make you partly responsible for violation of the law at the worst.
Do not serve an image that 'gloats' about your skill at blocking hotlinkers. The hotlinking Webmasters will take that as a challenge to steal your image (as mentioned above by D_Blackwell) or to attack your site intentionally. Information is power; Do not give power to your enemies.
Do not serve an image that accuses the hotlinking site of anything; Remember that many sites contain user-contributed content, and that the other site's Webmaster or owner may know nothing of the problem. If unsure, ask your lawyer. If you don't have lawyer, then don't take risks with libel laws...
Do not redirect these hotlinked requests somewhere else. This simply wastes internet bandwidth and passes the problem on to some other site or hosting company. Again, it's "bad citizenship."
If your hotlinking/image access problem is a serious one involving copyright and serious loss of revenue, then you'll need a better anti-hotlinking solution than that afforded by simple HTTP-Referer checking. Rewriting all image requests to a script that checks for authenticated users (e.g. "logged-in members") or the presence of a cookie set by an 'authorized page' on your site is one approach. If the images are really, really valuable, then you'll need to buy or write a client-server system where the images are transmitted as encoded objects to an application or plug-in on the client side and viewed in a proprietary viewer with controls to prevent any copying/screen-shotting whatsoever. Really, at this point, one begins to question whether the images should be electronically-published at all...
As above, serve an alternate image if it's 'profitable' to you, otherwise return a 403-Forbidden response and go on about your business -- Life's too short to dwell on minutiae.
To answer a question hinted-at in a post above, I replaced the regex subpattern "(jpeg¦jpg¦png¦gif)" with "(jpe?g¦png¦gif)" simply because the latter is a shorter, more-efficient, and entirely-equivalent pattern.
Jim
