cancel
Showing results for 
Search instead for 
Did you mean: 

RE your web page as been archived

Midnight_Caller
Rising Star
Posts: 4,154
Thanks: 9
Fixes: 1
Registered: ‎15-04-2007

Re: RE your web page as been archived

Well it still is not worked.  I can still link to the image.  See my test page.
Community Gaffer
Community Gaffer
Posts: 17,716
Thanks: 707
Fixes: 167
Registered: ‎05-04-2007

Re: RE your web page as been archived

That actually shows permission denied for me Gary so looks like it's working as intended. Once you've viewed the file normally though it will be cached and served each time so it looks like htaccess isn't doing it's job.
If this post resolved your issue please click the 'This fixed my problem' button
 Chris Parr
 Plusnet Staff
Midnight_Caller
Rising Star
Posts: 4,154
Thanks: 9
Fixes: 1
Registered: ‎15-04-2007

Re: RE your web page as been archived

It appears that it is working sort of.  Huh
But it is still not working fully.
Community Veteran
Posts: 26,786
Thanks: 986
Fixes: 10
Registered: ‎10-04-2007

Re: RE your web page as been archived

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.
jelv (a.k.a Spoon Whittler)
   Why I have left Plusnet (warning: long post!)   
Broadband: Andrews & Arnold Home::1 (FTTC 80/20)
Line rental: Pulse 8 Home Line Rental (£14.40/month)
Mobile: iD mobile (£4/month)
mikeb
Grafter
Posts: 367
Registered: ‎10-06-2007

Re: RE your web page as been archived

Looks like it's doing the job to me Smiley
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 Sad
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  Lips_are_sealed  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  Roll_eyes
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.
Midnight_Caller
Rising Star
Posts: 4,154
Thanks: 9
Fixes: 1
Registered: ‎15-04-2007

Re: RE your web page as been archived

For No Right Click Go HereWink  Smiley

oliverb
Grafter
Posts: 606
Registered: ‎02-08-2007

Re: RE your web page as been archived

Quote from: mikeb

However, the one big thing that isn't mentioned in that tutorial is "RewriteBase" and that's fundamentally important because, as I eventually found out after a phenomenal amount of messing around over many days/weeks back then, nothing much will work properly without setting it.

Silly question but what should it be set to? I'm confident its not / or /htdocs/ because those are just local paths anyway, as far as I know the absolute full path for plusnet is:
/share/isp/plusnet/www/<firsttwolettersofusername>/<username>/htdocs/
but I don't know if thats what the directive expects.
mikeb
Grafter
Posts: 367
Registered: ‎10-06-2007

Re: RE your web page as been archived

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  Tongue 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 Roll_eyes
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
puddy
Grafter
Posts: 1,571
Registered: ‎10-06-2007

Re: RE your web page as been archived

Thank you for all your help but a special thanks must go to mikeb for all his help and code writing THANKS MIKE
Kind regards
Puddy & Michael
oliverb
Grafter
Posts: 606
Registered: ‎02-08-2007

Re: RE your web page as been archived

Quote from: mikeb
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

At risk of false authority syndrome...
Looking at the example it appeared as if rewritebase was only needed when aliasing had been used. The problem seems to be when there is no direct mapping between server folders and website folders. I don't think mod_alias is even loaded?
I think by default mod_alias is applied first before mod_rewrite, but you can set it to pass the rewritten version back. I still don't quite get that bit...
Anyway I couldn't see any difference when I added it, so I took it out.
What does seem significant is that the filename passed to rewriterule is rooted at htdocs (unless its a subfolder or inheritance from a hosted domain). BUT the filename in %{REQUEST_FILENAME} appears to be absolute. This makes it trick to use the -f directive to make rules conditional on the file existing, since all the examples I've seen rely on the value in %{REQUEST_FILENAME} being identical to the value passed to rewriterule and assume you can just stick /folder/ in front of it. This is a shame as file-exists rules are amazing, you can have files in a subfolder and make it so URLs missing the foldername still work.
Want to see whats in one of those variables... Just add a rule that matches a test name, say "aardvark" and rewrites it to /index.htm?%{REQUEST_FILENAME} [L,R] , and when you look up "aardvark" you'll see your index but with the full filename and path as a parameter.
Also the paths appear to begin with a / always whereas in the examples they don't. That breaks every example of a URL canonization rule I've seen so far, so I've resorted to putting ^/?( in front of the pattern.
FWIW there ought to be a way to make money out of page popularity like that, maybe stuff a page full of keyword laden text and add as many banner ads as you can, then use referrer blocking to rewrite the image to return a very small gif showing the page URL.
mikeb
Grafter
Posts: 367
Registered: ‎10-06-2007

Re: RE your web page as been archived

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 Wink  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  Grin  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  Lips_are_sealed