RE your web page as been archived
It appears that it is working sort of. 
But it is still not working fully.
But it is still not working fully.
Quote from: jelv It appears that hasn't worked. Might it be because my site is on the same server as Puddy's? Can it be hot-linked from elsewhere.
Scrub that.
I had viewed the image directly to find out where it was located which had put it in my browser cache. Then when I went to my page it displayed it from cache. Having seen Gary's post I tried a CTRL+F5 and it didn't display.
Looks like it's doing the job to me 
A recently hotlinked image will not display but loading the same url manually (or right-click, view image in FireFox) displays the image. As others have already noted, once viewed 'officially' any attempts to view a hotlinked version will also display due to the image being cached locally. Clear the cache or force a full refresh and hotlinked images will disappear.
Unless someone is going to be really devious and is so desperate to steal bandwidth that they will try just about anything then this ought to prevent further problems. Unfortunately, there are still ways around it though but hopefully no one will really bother once they find it doesn't work easily. Most abuse comes from forums, blogs and myspace stylee sites etc. where there is often no particularly good reason for posting the hotlink in the first place, it's just part of some silly game of post-as-much-as-you-possibly-can and they've found a 'nice' picture. Trouble is it then gets 'n' 1000 hits a day for weeks of course
If you do get further problems then you might need to be even more draconian in how you restrict access. Deleting the line "RewriteCond %{HTTP_REFERER} !^$" would perhaps be the next step as this should stop the file being viewed except for via your own website. There is a possible side-effect with doing this however and users of some browsers may not be able to view your own site properly because the "referrer field" may not be sent. Disabling "right-click" to prevent someone from easily getting the filename is another possible restriction that would help a bit but I don't know how to do that off-hand. I don't think there is 100% fool-proof way of stopping the determined tho. I've always managed to get my hands on various things I strictly speaking shouldn't have despite any and all attempts to prevent me from doing so
See how it goes for now and hopefully all will be reasonably well any way. It can't possibly get as bad as it was before ... famous last words and all that again !
BTW, not sure what the media player stuff is but Ye Olde Computer and FireFox didn't like it. Both spent ages poncing around and eventually complained of some internal error and suggested a restart. W98 and my dislike of anything M$, media player in particular, probably didn't help mind you
You could definitely do with a dummy "index.htm" file in EVERY subdirectory to prevent 'curious' peeps (and there are lots of them around !) from poking around in your site content and finding stuff that you perhaps didn't want them to find. Anything will do just so long as there is valid "index.htm" that does nothing much apart from produce a blank page or says "go away" or similar. You could also add something in ".htaccess" to deal with it but keeping it simple and adding index files where required is probably the best thing for you to do.
You might also want to consider making your e-mail address less likely to be obtained by Mr.Spammer et al as well. There are no doubt better ways but putting something like "m<at>puddy<dot>co<dot>uk" will allow genuine peeps to contact you without it being quite so easily obtained by Mr.Spammer and his mates. Putting your address in an image file rather than plain text would be another alternative to deter all but those who genuinely want to contact you.
A recently hotlinked image will not display but loading the same url manually (or right-click, view image in FireFox) displays the image. As others have already noted, once viewed 'officially' any attempts to view a hotlinked version will also display due to the image being cached locally. Clear the cache or force a full refresh and hotlinked images will disappear.
Unless someone is going to be really devious and is so desperate to steal bandwidth that they will try just about anything then this ought to prevent further problems. Unfortunately, there are still ways around it though but hopefully no one will really bother once they find it doesn't work easily. Most abuse comes from forums, blogs and myspace stylee sites etc. where there is often no particularly good reason for posting the hotlink in the first place, it's just part of some silly game of post-as-much-as-you-possibly-can and they've found a 'nice' picture. Trouble is it then gets 'n' 1000 hits a day for weeks of course
If you do get further problems then you might need to be even more draconian in how you restrict access. Deleting the line "RewriteCond %{HTTP_REFERER} !^$" would perhaps be the next step as this should stop the file being viewed except for via your own website. There is a possible side-effect with doing this however and users of some browsers may not be able to view your own site properly because the "referrer field" may not be sent. Disabling "right-click" to prevent someone from easily getting the filename is another possible restriction that would help a bit but I don't know how to do that off-hand. I don't think there is 100% fool-proof way of stopping the determined tho. I've always managed to get my hands on various things I strictly speaking shouldn't have despite any and all attempts to prevent me from doing so
See how it goes for now and hopefully all will be reasonably well any way. It can't possibly get as bad as it was before ... famous last words and all that again !BTW, not sure what the media player stuff is but Ye Olde Computer and FireFox didn't like it. Both spent ages poncing around and eventually complained of some internal error and suggested a restart. W98 and my dislike of anything M$, media player in particular, probably didn't help mind you
You could definitely do with a dummy "index.htm" file in EVERY subdirectory to prevent 'curious' peeps (and there are lots of them around !) from poking around in your site content and finding stuff that you perhaps didn't want them to find. Anything will do just so long as there is valid "index.htm" that does nothing much apart from produce a blank page or says "go away" or similar. You could also add something in ".htaccess" to deal with it but keeping it simple and adding index files where required is probably the best thing for you to do.
You might also want to consider making your e-mail address less likely to be obtained by Mr.Spammer et al as well. There are no doubt better ways but putting something like "m<at>puddy<dot>co<dot>uk" will allow genuine peeps to contact you without it being quite so easily obtained by Mr.Spammer and his mates. Putting your address in an image file rather than plain text would be another alternative to deter all but those who genuinely want to contact you.
Highly entertaining (NOT) isn't it when you consider paths to what are just 'simple' files on your webspace ... for an index file in the root directory of your website, is it:
index.htm
/index.htm
/htdocs/index.htm
/share/isp/plusnet/www/u_n/user_name/htdocs/index.htm
I did (and still do) get completely confused by exactly where and when paths get stripped and added back as well as by the fundamental 'translation' of paths that obviously goes on between the website 'location' of a file and it's actual location as stored on the server. I spent absolutely ages poncing around with .htaccess files years back with no end of strange problems and it seemed that no one could really explain the ins and outs of the processing in terms that didn't add even more confusion ! There is lots of info in the Apache manuals and plenty of other places as well but not having a Degree in Geek Speak
or similar and not really understanding the finer points of how a webserver actually works in the first place, I found most if not all of this simply added to the confusion rather than helping.
I've just had a few attempts to write something myself to explain what actually happens as I understand it and provide some real examples but have failed dismally because even when I read it back, it still wasn't that clear. As I said earlier, something definitely does need to be added to the existing help page and as Maurice has already suggested, I will have a go at it, but if it's not 100% crystal clear to Mr.Average then it's just not going to help in the slightest. I'll have another go (or 12 !) sometime later to see if I can finally come up with a (hopefully) correct but at least 100% understandable explanation. Don't hold your breath though
However, the bottom line is that each and every .htaccess file you have MUST have a "RewriteBase" line or some (most) things wont work properly. It's really only relevant if you are actually changing URLs from one thing to another and particularly if you are redirecting elsewhere though. Simple things like preventing hotlinking or effectively rewriting URLs to standard error pages in general do not actually need it but I still think that it's good practice to have it there regardless. Believe me, it saves a whole load of unnecessary confusion and many, many hours/days/weeks of screaming, shouting, kicking PCs and hair pulling etc. should you ever decide to do some more complex rewriting in the future.
I think the best (and hopefully totally correct) way to think of it is that the "RewriteBase" line should point to the website 'location' of the .htaccess file that it's contained in. For instance,
/.htaccess (which appears to the user when FTPing as being htdocs/.htaccess) should contain the line "RewriteBase /"
/images/.htaccess (which appears to the user when FTPing as htdocs/images/.htaccess) should contain the line "RewriteBase /images/"
/downloads/.htaccess (which appears to the user when FTPing as htdocs/downloads/.htaccess) should contain the line "RewriteBase /downloads/"
... and so on. I really hope that's right but that's the conclusion I finally came to and TBH, I totally gave up trying to fully understand exactly what is going on, where it's going on and why it's going on. I just want to use the *&^£%$& server and rewrite URLs occasionally not be able to start a 2 hour lecture on how it works to someone who probably doesn't want to know in the first place and then watch their eyes glaze over after the first 30 seconds ! However, what's most important is that setting "RewriteBase" as above does actually work in all the instances where I've used it whereas not doing so means it most certainly does not work.
BTW, I notice that quite a few peeps have DL'd the .htaccess file I posted a link to. No problems at all with that but please do remember that it was written SPECIFICALLY for puddy and therefore it WILL NOT work for anyone else UNLESS you edit the code so that it's relevant to YOUR website.
This is the generic code:
The highlighted bit in the 3rd line needs to be edited accordingly and it should be something like one of these (with the your_domain or your_user_name bit replaced with exactly what it is of course) :
your_domain\.co\.uk
your_domain\.com
your_user_name\.plus\.com
your_user_name\.f9\.co\.uk
In all cases, any 'special' characters (such as a ".") MUST be prefixed with a back slash "\" because otherwise, the "." actually means "any character" which could result in some unexpected problems. BTW, the (.+\.)? before your_domain... 'simply' means that it should also work if the data being processed is actually www.your_domain... or subdomain.your_domain... and so on rather than only matching your_domain...
The highlighted bit in the 5th line will also need to be edited accordingly if you have other file types that you want to prevent hotlinking to and it should look something like this:
jpe?g|gif|bmp|png|wmv|wma|swf|pdf
It is simply a list of file extensions, each separated by a 'pipe' character "|", so add or delete as required. BTW, the jpe?g is simply a shorter way of putting jpeg|jpg
index.htm
/index.htm
/htdocs/index.htm
/share/isp/plusnet/www/u_n/user_name/htdocs/index.htm
I did (and still do) get completely confused by exactly where and when paths get stripped and added back as well as by the fundamental 'translation' of paths that obviously goes on between the website 'location' of a file and it's actual location as stored on the server. I spent absolutely ages poncing around with .htaccess files years back with no end of strange problems and it seemed that no one could really explain the ins and outs of the processing in terms that didn't add even more confusion ! There is lots of info in the Apache manuals and plenty of other places as well but not having a Degree in Geek Speak
or similar and not really understanding the finer points of how a webserver actually works in the first place, I found most if not all of this simply added to the confusion rather than helping.I've just had a few attempts to write something myself to explain what actually happens as I understand it and provide some real examples but have failed dismally because even when I read it back, it still wasn't that clear. As I said earlier, something definitely does need to be added to the existing help page and as Maurice has already suggested, I will have a go at it, but if it's not 100% crystal clear to Mr.Average then it's just not going to help in the slightest. I'll have another go (or 12 !) sometime later to see if I can finally come up with a (hopefully) correct but at least 100% understandable explanation. Don't hold your breath though
However, the bottom line is that each and every .htaccess file you have MUST have a "RewriteBase" line or some (most) things wont work properly. It's really only relevant if you are actually changing URLs from one thing to another and particularly if you are redirecting elsewhere though. Simple things like preventing hotlinking or effectively rewriting URLs to standard error pages in general do not actually need it but I still think that it's good practice to have it there regardless. Believe me, it saves a whole load of unnecessary confusion and many, many hours/days/weeks of screaming, shouting, kicking PCs and hair pulling etc. should you ever decide to do some more complex rewriting in the future.
I think the best (and hopefully totally correct) way to think of it is that the "RewriteBase" line should point to the website 'location' of the .htaccess file that it's contained in. For instance,
/.htaccess (which appears to the user when FTPing as being htdocs/.htaccess) should contain the line "RewriteBase /"
/images/.htaccess (which appears to the user when FTPing as htdocs/images/.htaccess) should contain the line "RewriteBase /images/"
/downloads/.htaccess (which appears to the user when FTPing as htdocs/downloads/.htaccess) should contain the line "RewriteBase /downloads/"
... and so on. I really hope that's right but that's the conclusion I finally came to and TBH, I totally gave up trying to fully understand exactly what is going on, where it's going on and why it's going on. I just want to use the *&^£%$& server and rewrite URLs occasionally not be able to start a 2 hour lecture on how it works to someone who probably doesn't want to know in the first place and then watch their eyes glaze over after the first 30 seconds ! However, what's most important is that setting "RewriteBase" as above does actually work in all the instances where I've used it whereas not doing so means it most certainly does not work.
BTW, I notice that quite a few peeps have DL'd the .htaccess file I posted a link to. No problems at all with that but please do remember that it was written SPECIFICALLY for puddy and therefore it WILL NOT work for anyone else UNLESS you edit the code so that it's relevant to YOUR website.
This is the generic code:
Quote RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?your_domain\.co\.uk [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ -
The highlighted bit in the 3rd line needs to be edited accordingly and it should be something like one of these (with the your_domain or your_user_name bit replaced with exactly what it is of course) :
your_domain\.co\.uk
your_domain\.com
your_user_name\.plus\.com
your_user_name\.f9\.co\.uk
In all cases, any 'special' characters (such as a ".") MUST be prefixed with a back slash "\" because otherwise, the "." actually means "any character" which could result in some unexpected problems. BTW, the (.+\.)? before your_domain... 'simply' means that it should also work if the data being processed is actually www.your_domain... or subdomain.your_domain... and so on rather than only matching your_domain...
The highlighted bit in the 5th line will also need to be edited accordingly if you have other file types that you want to prevent hotlinking to and it should look something like this:
jpe?g|gif|bmp|png|wmv|wma|swf|pdf
It is simply a list of file extensions, each separated by a 'pipe' character "|", so add or delete as required. BTW, the jpe?g is simply a shorter way of putting jpeg|jpg
As I said earlier, it was a long time ago and I went round and round and round in circles and all that at the time trying to fully understand exactly what happens and where/when in the process it happens. But the gist of it, I think, was that the server handles the translation between website 'location' and actual location by way of conversion/aliasing. This is standard practice and nothing new, different or unusual in any way. Nothing to be concerned about, it's part of the general server configuration and nothing that can be altered in any way by a remote user.
However, processing .htaccess (when present) occurs way too late in the normal sequence of events therefore if any rewrite action takes place here, the new URL has to be passed back to go around the loop again. The full path to the URL had been stripped prior to reaching .htaccess and therefore this needs to be replaced before injecting the URL back into the processing much nearer the start. Unfortunately, the default action is to add back a path based on actual server file location rather than website 'location'. This is virtually never an appropriate action because few if any sites will have identical website file 'location' and actual server file location. In the case of servers such as at PN it is absolutely guaranteed that the website and actual server locations will be totally different.
If the default action takes place, this effectively means that the URL now has a path to a file on the actual server rather than a path to the website 'location'. The end result is total chaos and confusion because the earlier processing will then attempt to convert/alias this URL on the assumption that it is (as would normally be the case) a path to a website 'location' as received from a browser. The RewriteBase command overrides the default action and therefore reconstructs the URL so that it is much the same as a URL that would have been received by the server had the user requested the rewritten URL manually.
That's my simplistic understanding but I freely admit that I'm a million miles away from being anything even remotely close to any sort of expert ! All I do know is that not setting RewriteBase as described above and then having a .htaccess file that does actually tweak URLs (rather than just responds with an error message #403 #404 or whatever to certain URLs) or one that rewrites completely different URLs (i.e. effectively a conditional redirect to a server/file elsewhere) is a recipe for disaster, much time wasting and severe long-term hair pulling.
When the unexpected happens, you can only find out what was actually going on a couple of days later of course when you get your access logfiles. There you will see why you were getting #403's or a variety of strange and unexplained behaviour or whatever all over the place rather than what you wanted to happen because the rewritten URLs would be appearing in your logs as something like:
/share/isp/plusnet/www/u_n/user_name/htdocs/something.something
rather than
/something.something
one or other or both of which might have been prefixed by www.your_website.com or whatever, I can't quite remember now, but the reality was that rewriting simply doesn't work properly unless you set an appropriate RewriteBase because the default action that will be taken if you don't is not even remotely close to being an appropriate action to take.
I have a truly monster .htaccess in my root directory. It tweaks no end of things all the time. I use it to map different avatars used on different forums to the same actual file(s) so that I see unique hits for each in my logs without having 'n' versions of the same file hanging around needing maintaining. ditto for posted images and so on in general. I use it for changing avatars depending on calendar date. I use it to serve different looking pages to different IPs, different browsers or when requested from different places despite the incoming URLs all being identical. I use it to ban lots of rogue sites and IPs from accessing any of my stuff. I use it give preference to certain URLs from certain places. I use it to make certain files only available for DL at certain times of the day, week or month or only to certain IPs. I use it to serve, shall we say, 'interesting', 'different' and totally unexpected files to various known abusers who insist on hotlinking to my stuff and refuse to remove links from their sites or forums.
All this and so much more ... but without RewriteBase being set, I can assure you that it all goes very much mammaries elevated !!
PS: and yes, you're right, sending abusers off to somewhere inappropriate and/or a money-making page is very much a good idea and a quite easily made arrangement
I haven't done that as such yet but I most certainly do frequently substitute things in place of the hotlinked image they were expecting to see when I spot abusers in my daily wander through my logfiles. Always rather amusing to see an advert to a competitor site (or perhaps something a lil naughty or otherwise inappropriate) appearing in the middle of some abusers site 
Any myspace et al users around here who have previously hotlinked to any of my stuff will already know what happens and exactly how embarrassing it generally becomes without need for any further explanation on a family site such as this
However, processing .htaccess (when present) occurs way too late in the normal sequence of events therefore if any rewrite action takes place here, the new URL has to be passed back to go around the loop again. The full path to the URL had been stripped prior to reaching .htaccess and therefore this needs to be replaced before injecting the URL back into the processing much nearer the start. Unfortunately, the default action is to add back a path based on actual server file location rather than website 'location'. This is virtually never an appropriate action because few if any sites will have identical website file 'location' and actual server file location. In the case of servers such as at PN it is absolutely guaranteed that the website and actual server locations will be totally different.
If the default action takes place, this effectively means that the URL now has a path to a file on the actual server rather than a path to the website 'location'. The end result is total chaos and confusion because the earlier processing will then attempt to convert/alias this URL on the assumption that it is (as would normally be the case) a path to a website 'location' as received from a browser. The RewriteBase command overrides the default action and therefore reconstructs the URL so that it is much the same as a URL that would have been received by the server had the user requested the rewritten URL manually.
That's my simplistic understanding but I freely admit that I'm a million miles away from being anything even remotely close to any sort of expert ! All I do know is that not setting RewriteBase as described above and then having a .htaccess file that does actually tweak URLs (rather than just responds with an error message #403 #404 or whatever to certain URLs) or one that rewrites completely different URLs (i.e. effectively a conditional redirect to a server/file elsewhere) is a recipe for disaster, much time wasting and severe long-term hair pulling.
When the unexpected happens, you can only find out what was actually going on a couple of days later of course when you get your access logfiles. There you will see why you were getting #403's or a variety of strange and unexplained behaviour or whatever all over the place rather than what you wanted to happen because the rewritten URLs would be appearing in your logs as something like:
/share/isp/plusnet/www/u_n/user_name/htdocs/something.something
rather than
/something.something
one or other or both of which might have been prefixed by www.your_website.com or whatever, I can't quite remember now, but the reality was that rewriting simply doesn't work properly unless you set an appropriate RewriteBase because the default action that will be taken if you don't is not even remotely close to being an appropriate action to take.
I have a truly monster .htaccess in my root directory. It tweaks no end of things all the time. I use it to map different avatars used on different forums to the same actual file(s) so that I see unique hits for each in my logs without having 'n' versions of the same file hanging around needing maintaining. ditto for posted images and so on in general. I use it for changing avatars depending on calendar date. I use it to serve different looking pages to different IPs, different browsers or when requested from different places despite the incoming URLs all being identical. I use it to ban lots of rogue sites and IPs from accessing any of my stuff. I use it give preference to certain URLs from certain places. I use it to make certain files only available for DL at certain times of the day, week or month or only to certain IPs. I use it to serve, shall we say, 'interesting', 'different' and totally unexpected files to various known abusers who insist on hotlinking to my stuff and refuse to remove links from their sites or forums.
All this and so much more ... but without RewriteBase being set, I can assure you that it all goes very much mammaries elevated !!
PS: and yes, you're right, sending abusers off to somewhere inappropriate and/or a money-making page is very much a good idea and a quite easily made arrangement
I haven't done that as such yet but I most certainly do frequently substitute things in place of the hotlinked image they were expecting to see when I spot abusers in my daily wander through my logfiles. Always rather amusing to see an advert to a competitor site (or perhaps something a lil naughty or otherwise inappropriate) appearing in the middle of some abusers site Any myspace et al users around here who have previously hotlinked to any of my stuff will already know what happens and exactly how embarrassing it generally becomes without need for any further explanation on a family site such as this