본문 바로가기

Server

이미지, 동영상 불펌 막기


URL : http://www.thesitewizard.com/archive/bandwidththeft.shtml

Preventing Image Bandwidth Theft With .htaccess
by Christopher Heng, thesitewizard.com


Judging from thesitewizard.com's web statistics, my article "How to Protect Your Images from Bandwidth Theft (PHP Script)" appears to be exceedingly popular. And no wonder too: I read complaints about websites stealing another site's images and making the victim pay for their bandwidth almost every other day. This article provides another solution to the problem of bandwidth theft, one that does not require the webmaster to modify any existing web pages nor install any scripts.


System Requirements
The solution outlined in this article requires your site to be hosted on a machine using the Apache web server and that your web host allows you to override the server's configuration using a .htaccess file. For the more technically inclined, it uses the facilities provided in the mod_setenvif Apache module.


If this is not the case for your website, you cannot use the suggestions given here. You might wish to check out my PHP solution, How to Protect Your Images from Bandwidth Thieves, instead. The article may be found at http://www.thesitewizard.com/archive/protectimages.shtml


(To find out if your web server fulfills the requirements stated here, try checking up the documentation on your web host's website - the information is usually available on their list of web hosting packages, price lists or on their order form. Alternatively, contact their technical support and find out from them.)


Steps to Take
Protecting your images using a .htaccess file is trivial.


Put all the images you wish to protect from being stolen (bandwidth-wise) in a separate directory.


Create an ASCII text file named .htaccess and save it in that directory. Note that the name starts with a fullstop (or period) and is entirely in small letters (ie, lowercase). Cut and paste (unless you're using IE 6 in which case you just have to type it yourself) the following lines into that file:


SetEnvIfNoCase Referer "^http://www.your-domain-name-here.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://www.your-domain-name-here.com$" locally_linked=1
SetEnvIfNoCase Referer "^http://your-domain-name-here.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://your-domain-name-here.com$" locally_linked=1
SetEnvIfNoCase Referer "^$" locally_linked=1
<FilesMatch "\.(gif|png|jpe?g)$">
  Order Allow,Deny
  Allow from env=locally_linked
</FilesMatch>

Change "your-domain-name-here.com" to your real domain name. If your site can be accessed using other domain names (eg "www.your-domain-name-here.net"), be sure to add an additional SetEnvIfNoCase line for each of those domain names (with the URLs appropriately changed to the URLs of your domains. On the other hand, if your site can only be accessed using one domain, for example, using only "www.your-domain-name-here.com", then delete the line with "http://your-domain-name-here.com". The cut and paste code above caters to the usual case where most sites can be accessed with or without the "www" prefix.


Do not correct my spelling in the code snippet given above. "Referer" (with only one "r" in the middle of the word) is the word that needs to go into the .htaccess file - do not change it to "Referrer".


That's all there is to it. The above file should protect all images that have ".gif", ".png", ".jpg" and ".jpeg" extensions.


Remember to use an ASCII text editor (also known as "text editor" or "plain text editor") to create the .htaccess file. Do not use Microsoft Word or Wordpad. Notepad (found on all Windows systems) is fine.


Explanation: .htaccess to Block Unauthorized Image Usage
Whenever a browser sends your web server a request for an image, it usually also sends the URL of the page that linked to that image. The above .htaccess file causes the server to check this URL ("Referer" in the above snippet) and if it is one of the authorized URLs that you specify, it will set an internal flag called "locally_linked". This internal flag is technically called an "environmental variable". If the URL sent is not in this list of authorised URLs, the flag (or environment variable) is not set. Note that we also set the "locally_linked" variable if the browser does not send any URL at all: this occurs when the visitor accesses your site using a browser or a proxy that suppresses the referring URL.


The web server then checks if the file requested has an extension in the list given above (gif, png, jpg and jpeg). If so, and the "locally_linked" variable is set, it will send the image. Otherwise it an error will be sent.


What Happens When A Bandwidth Thief Links to Your Image
After you create the .htaccess file, if some other site tries to link to your image from their site, they will find that the image will not display on their site. On the other hand, your images should generally load fine on pages on your site.


Potential Problems
Like the PHP solution, this method relies on the HTTP_REFERER variable (the variable that contains information about the referring page) being properly sent by the visitor's browser. A number of modern browsers as well as some of the anonymous surfing proxies and firewalls allow the user to change this header. These browsers or proxies will thus either transmit HTTP_REFERER headers that have some user-specified value or not bother to transmit them at all. There are also buggy browsers around that unpredictably transmit the wrong HTTP_REFERER header on occasion.


When this occurs your visitor will either not view the image even when he is on your site (which means that your own page will have broken link images), or he may be able to view your images even when it is displayed on the copyright infringing thief's site.


Hopefully the percentage of people who encounter this is small, but you have to be aware that these situations do occur.

'Server' 카테고리의 다른 글

아파치 서비스 등록  (0) 2008.10.22
Ping으로 서버 OS종류 알기  (0) 2008.10.18
svnadmin help create  (0) 2007.07.09
httpd.conf : Apache+OpenSSL+ViewVC  (0) 2007.07.02
포트 동접 체크  (0) 2007.05.29