Forum Moderators: phranque
Welcome to WebmasterWorld!
There's no simple answer to this. A download request is indistinguishable from a typed-in page request. In fact, if a page has been "viewed" then it has already been donwloaded.
Many HTTP_Referer-based "anti-download" and "anti-hotlink" solutions have been proposed and are available here and on the Web. But they all suffer from two drawbacks: HTTP_Referers can be blocked by legitimate corporate and ISP caching proxies, and HTTP_Referers can be easily spoofed. Therefore, while easy to implement, the effectiveness of referer-based solutions is minimal.
One of the simplest effective solution involves the use of cookies and a script to serve the protected content. Set a cookie on a page that allows access to the doanloadable content. Use mod_rewrite to rewrite all requests for the protected content URL to a script. The script checks the cookie, and if present and valid, performs the download. Otherwise, it can serve something else.
Obviously, this may appear to be complex if these subjects are new to you. But if you want to protect your content, then the research path is pretty-well defined.
Jim
It's not the only prog of it's type out there that can do this ....it is however stopped by passwords in most circumstances ...depends if you are trying to protect against "detertmined hacker intrusion" or just "drive by file heists"...
The former is much harder and without physical control ( ie: you can sit and touch it! ) the protection of your server /data can never really be assured ...
You can deter most drive bys to the point where they give up or buy a soft such as the one mentioned to get around your defenses...
I do know one way ( there's others more complex ) to defeat the widow et al which invovles deliberately mashing your basic nav structure links ..they can be read by IE, Firefox etc and even by the broswer thats in the widow ..but they cannot be be passed to the FTP inbuilt client as they are not parsable ..( found it while reparing a site made for a customer that had some nav faults and I couldnt' get the structure to load or it's directories " the quick way" ...client was not available for a couple of hours ( he was on the beach with no cell phone ; ) to give me the server passwords to get the FTP entrance open "normally"...
Opened just fine in all browsers but defeated the "quick 'n' dirty" way in ...
Last webmaster had made it in Frontpage and made a mistake with a very tricky css nav box link combo ( which also made the site choke the search engines ) but!...made it 99 % downloadable proof ...but readable ...( first time I 've ever seen a positive outcome of the extra code that Frontpage adds on ..even if he had edited it ..made loads of mistakes in doing so and so corrupted it ..it ran in normal browsers ..but downloaders just couldn't work out where the links went ) ...
I know he didn't design it this way cos only IE could get past the first page ( all other browsers just couldnt load the nav system after page one or the first click on the nav ) due to the edits he had made to the front page code ( the nav system wasn't the only thing he had screwed up )...IE seems to read corrupted frontapage kludge better than the non Redmond "family" items ...
Only the first page validated at WC3 for xtml ...the rest made the validator shake it's head ...
He presented it as "finished" to the client ..who asked me to explain to him why his partners who weren't using IE couldnt get onto their own site ..and the webdesigner /master couldn't fix it ...he only checked it in IE ...;) ..bless 'im!
There is a way ( albeit very, very complex and requiring the site to be served up by javascript to IE which in conjunction with what Jim refered to ( and using this "bad code" that I happened across that means that only IE can nav the site ) that can shut off virtually all copying /downloading facilty as it also kills the toolbar in IE , the clipboard in IE and the temp internet files are shut off from "user" access for the "user" session duration ..actaully all users must reboot and therefore lose the data ..in order to get the toolbar, clipboard and their temp internet files access back again ...so no "sneakarounds"..
if they switch off the javascript they see nothing of what you want to hide or subsequently protect
But you will piss off a lot of visitors if they have to enable javascript to see the content and then in doing so you kill most of their machines options for the remainder of the doze session ...I stopped using it for this reason ( at the time I was not aware of the nav "bad code" existance...or I might have been tempted to keep using it ...
As Tedster pointed out politely to me at the time ...alienating the visitor isn't the way to win hearts and make google your friend on the internet ...
However ..
If you combine all of the above things you can stop virtually eveyone from gatting or keeping your data or as was in my case images ( at the time I hadn't done the htacces and ronin just got the pics that way ;) ..but if you add it all up it stops 99% ..
Bear in mind tho ..annoy someone enough ..they may just deface your server ...
If you want the script in spite of all that ( it does require totally redesigning your site to make it work smoothly ..it was custom written for an image based site ..needs page Id"s, hidden calls , crypting of script and calls to the script ... ) ...sticky me and I'll see about making a variant that can be used to protect data files of all types ...but it does involve what can only honestly be described as hacking the client machine that connects to it as the javascript forces activeX to kick in ...it's not 100% "diss" proof ..and SP2 made it a touch less effective ..but if you really are desperate and want to show why and what you need to protect ( some stuff I will not touch ) ...let me know ..
