С любезното съдействие на Михаил Новак (Floyd)
.htaccess (hypertext access) е името по подразбиране на конфигурационен файл за Apache web-сървъри, който има въздействие в рамките на директория и нейните поддиректории. Файлът позволява задаване на специфични (различни от общите настройки) свойства и правила за достъп. Името на файла започва с точка. По конвенция такива файлове в UNIX и производните и операционни системи се третират като скрити файлове.
Вероятно щом сте тук, сте се срещали вече с файла .htaccess, но също така вероятно повечето от вас не са наясно с пълните възможности, които предоставя този файл. Напълно възможно е и никога да не сте използвали или никога да не ви се наложи да използвате .htaccess. Във всички случаи е добре да знаете пълните възможности на този специален файл.
Освен популярните му приложения, като подмяна на стандартните страници за показване на грешки, защита с пароли на определени директории и забрана на достъпа от определени IP адреси, .htaccess предлага и още много възможности.
1. Няколко основни разяснения и съвети
Незапознатите с .htaccess следвайки логиката на конвенцията за имена на файловете, често се объркват, че става въпрос за разширение на файл. .htaccess не е разширение, а име на файл. Или иначе казано не става въпрос за „file.htaccess”, а просто за „.htaccess”.
.htaccess е обикновен текстов ASCII файл, който можете да създадете с всеки текстов редактор, като „Notepad” или „SimpleText” например. За да създадете такъв файл отворете текстовия редактор и при записа задайте име на файла „.htaccess”.Ако използвате Notepad, вероятно ще получите файл с име „.htaccess.txt”. Не се учудвайте - както повечето програми на Microsoft така и Notepad държи да ви помогне (което по мое лично мнение в обикновено пречи). Просто преименувайте файла. За да има ефект, името на файлът трябва да бъде точно „.htaccess” (без кавичките разбира се).
Ако качвате файла на отдалечен сървър използвайте ASII режим.
След като файлът бъде поставен в необходимата директория на сървъра, уверете се, че има режим на достъп „RW-R--R--” (или 644), ако не - променете го с командата chmode. Това е изключително важно. Така зададения режим гарантира, че файлът е достъпен за сървъра, но не и за браузърите. В противен случай е възможно вашият .htaccess да бъде прочетен от всеки, което е сериозен пробив във сигурността, особено ако имате защитени с пароли директории (повече подробности - по късно).
Повечето команди в .htaccess се записват на един ред. За да не се обърквате или при запис да повредите целостта на линиите, изключете опцията „word wrap” на редактора.
.htaccess е създаден за Apache и UNIX (съответно производните на UNIX OC. Вкл. Linux). И макар, че в NT сървърите има подобно действие, не може да се разчита на пълна съвместимост. Тук ще говорим за приложението му в UNIX и UNIX-производни ОС.
.htaccess има въздействие както за директорията в която се намира така и за всички поддиректории. Тоест, ако поставите .htaccess във вашата основна директория, той ще има въздействие за целия сайт. В този случай е важно да се знае, че можете да поставите и други .htaccess файлове надолу в дървото, като те заменят напълно (не допълват, а заменят!) по-горния в дървото .htaccess. Или простото правило е „важи най-близкия по посока root .htaccess”.
Преди да създадете и поставите вашите .htaccess файлове помислете внимателно доколко са необходими, дали няма да предизвикат зациклени пренасочвания или други грешки.
Още, ако използвате хостинг е възможно администратора да е забранил използването на .htaccess файлове например поради факта, че забавят като цяло работата на сървъра или позволяват заобикаляне на някои ограничения. Най-добре се консултирайте с администратора за да избегнете евентуални неприятности.
2. Промяна на стандартните съобщения за грешки (Error Documents)
За да създадете собствени страници със съобщения за грешки, преди всичко е необходимо да сте на ясно с кодовете, които сървърът генерира (показани са в таблицата по-долу). Не е необходимо да създавате страници за всички кодове, а за някои кодове това е недопустимо. Например създаване на страница за код 200 ще доведе до безкраен цикъл, което естествено не е добре.
Кодове на състоянията:
Successful Client Requests
200 OK
201 Created
202 Accepted
203 Non-Authorative Information
204 No Content
205 Reset Content
206 Partial Content
Client Request Redirected
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy
Client Request Errors
400 Bad Request
401 Authorization Required
402 Payment Required (not used yet)
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable (encoding)
407 Proxy Authentication Required
408 Request Timed Out
413 Request Entity Too Long
414 Request URI Too Long
415 Unsupported Media Type
Server Errors
500 Internal Server Error
501 Not Implemented
404 Gateway Timeout
505 HTTP Version Not Supported
Нормално задаване на нестандартни страници за съобщения се прилага за грешките - група 4xx (Client Request Errors) и 5xx (Server Errors). Най-често това са:
404 - възниква, когато браузъра се обърне към несъществуваща страница,
500 - когато възникне грешка в текущо изпълнявания скрипт,
401 - при неуспешен опит за отваряне на защитена с име и парола страница,
403 - когато режима на достъп не позволява отваряне на страницата от браузър,
400 - когато HTTP заявката не отговаря на стандарта ...
За да зададете ваша страница, която да се върне на браузъра при възникване на някое от състоянията от таблицата по-горе, е необходимо да запишете в .htaccess по един ред за всеки код. Синтаксиса е:
ErrorDocument code /directory/filename.ext
Например:
ErrorDocument 404 /errors/notfound.html
Ако .htaccess е поставен в корена на „yoursite.com”, то при възникване на грешка 404 сървърът ще върне като резултат „yoursite.com/errors/notfound.html”. По същия начин за грешка с код 500 може да запишете:
ErrorDocument 500 /errors/internalerror.html
Можете да давате произволни имена на вашите страници за съобщения, както и да ги поставяте на което и да е web-достъпно място на сървъра, но все пак е по-добре да ги поставите в една директория и да им дадете имена, които отговарят на значението им. Това ще ви помогне да се ориентирате след време. Наклонената черта в началото на пътя показва, че адресирането е спрямо корена „root” на вашия сайт. Обичайно решение е тези страници да се поставят в една директория под корена (например „/errors/”), която е забранена за индексиране от търсачките чрез файла „robots.txt”. Едно обичайно разположение е:
ErrorDocument 400 /errors/badrequest.html
ErrorDocument 401 /errors/authreqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/serverr.html
Допустимо и задаване на абсолютни URL, като:
ErrorDocument 404 http://theMySyte.net/errors/notfound.html
но така няма да можете да използвате готовите вече фрагменти за други ваши сайтове.
3. Защитени директории
Ако искате определени директории от вашия сайт да са достъпни само за определени хора и да сте сигурни, че не възможно някой с достатъчно познания да достигне до вашите скриптове или друг сорс код, то .htaccess е решението, което ви трябва.
Има различни механизми за защита на определени области: сървърно базирани (ASP, PHP, Perl и други) или клиент-базирани (JavaScript). Последните са достатъчно несериозни за да се спираме на тях.
Например в PHP можете да защитите страници чрез включване на подходящи HTTP хедъри („WWW-Authenticate: Basic realm=....”, „HTTP/1.0 401 Unauthorized”) и използване на суперглобалните променливи „$_SERVER['PHP_AUTH_USER']” и „$_SERVER['PHP_AUTH_PW']”. Но също така можете да използвате и възможностите, които предоставя .htaccess, като предимството е, че няма да се наложи да пишете програмен код.
Първото, което трябва да направите е да създадете файл наречен .htpasswd. Името на файла, начина на ъплоуд и режима на достъп отговаря на същите правила, както и .htaccess. За подробности се върнете в началото на урока. В този файл се записват имената и съответните им пароли (в криптиран вид) с които единствено може да се разреши web-достъп до директорията в която се намира съответния .htaccess файл. .htpasswd файлът трябва да съдържа по един ред за всеки оторизиран потребител.
Синтаксиса е следния::
user1:password1
user2:password2
...
За криптиране на паролите може да използвате например handy-dandy tool.
От съображения за сигурност, трябва да поставите файла с паролите в директория, която не е web-достъпна.
Какво трябва да запишете в .htaccess:
AuthUserFile [i]usr/local/you/safedir[/i].htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user user1
Първия ред указва пълния път спрямо корена до файла с допустимите потребители, но забележете, че на последния ред е указан само user1. Това е подходящ синтаксис, ако желаете определени потребители да имат достъп до определени директории. Ако искате всички описани в посочения .htpasswd файл потребители да имат достъп до директорията, използвайте записа: „require valid-user”.
AuthName е името на защитената област. Можете да замените това име с по-подходящо според случая. Например „Restricted Area”. AuthType е типа на използвания механизъм. В случая - Basic.
4. Разрешаване на SSI чрез htaccess
Много програмисти биха искали да използват удобствата, които предлага SSI (Server Side Includes), но не могат поради ограничение наложено от администратора на техния хостинг. Можете да промените това, чрез .htaccess, но първо се уверете, че по този начин не нарушавате правилата за ползване. Най-добре е да говорите с администратора.
AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes
Първата линия указва на сървъра, че страниците с разширение .shtml (Server parsed HTML) са валидни. Втората линия включва сървърния парсер за файлове с разширение .shtml. Тоест указва на сървъра, че тези файлове трябва да се проверяват за SSI команди (и съответно изпълняват). Последната линия е просто техническа подробност, но трябва да присъства.
И това е. Сега можете да използвате SSI. Не бързайте да променяте разширенията на всичките си файлове на .shtml. Просто вмъкнете като втора линя в горния код:
AddHandler server-parsed .html
Това ще накара сървъра да проверява и .html файловете за SSI команди. Идеята не е много добра доколкото ще доведе до допълнително излишно натоварване на сървъра, но пък ще ви спести време. А и е един вид елементарна защита, тъй като не подсказва на потребителите, че страницата съдържа SSI инструкции, които могат да станат обект на хакерски намеси. Както обикновено най-добре е да прецените сами според случая дали да използвате тази опция. Ако решите да разделите страниците на .shtml и .html, тази втора линия не ви е необходима. Ако не сте сигурни какво ще правите, добавете:
DirectoryIndex index.shtml index.html
Този ред задава страницата по подразбиране да бъде index.shtml, а ако такава липсва, ще се зареди index.html. Още за подразбиращата се страница ще разгледаме по-късно.
5. Блокиране на достъпа от определени IP адреси
Има хора или групи, които опитват да причинят вреди на сайта ви? - Има и решение- блокирайте достъпа им! Добавете код подобен на този (всяка команда е на отделен ред):
order allow,deny
deny from 123.45.6.7
deny from 012.34.5.
allow from all
Можете да блокирате достъпа на определен IP адрес или интервал от адреси. В горния пример е блокиран достъпа от адрес 123.45.6.7, както и от всички адреси започващи с 012.34.5. (012.34.5.0, 012.34.5.1 ...... 012.34.5.255). Втория вариянт едва ли има практическо приложение, но е допустим.
Можете още да използвате забрана за всички: deny from all. Освен IP адреси може да се използват и имена на домейни: deny from .knowhacker.com, което ще забрани достъпа от всички поддоменйни на knowhacker.com (www.knowhacker.com, virtual.knowhacker.com и т.н.).
6. Блокиране на достъпа на потребител / домейн по начина на обръщение
Блокирането на трафика за потребители или сайтове който минава през определен домейн е друг вариант за ограничаване на достъпа. Да предположим, че разглеждате вашите лог-файлове и забелязвате голямо количество обръщения от определен сайт. Когато обаче прегледате въпросния сайт не откривате никъде линк към вашия. Обръщенията към вашия сайт явно са необичайни. Вероятно става въпрос за използване на ресурси от вашия сайт като изображения, .css файлове и други, които се знае, че не се променят. Като се има предвид, че в log-файловете се записват всички видове обръщения, както и информация от къде са дошли, можете да решите да спрете някои от тях.
За да направите това обаче, преди всичко е необходимо да имате инсталиран модул mod_rewrite на вашия Apache сървър. По подразбиране този модул се инсталира заедно със сървъра, но все пак проверете. И така за да забраните целия трафик породен от обръщение през определен домейн, използвайте следния код:
За един домейн:
RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} badsite\.com [NC]
RewriteRule .* - [F]
За няколко домейна:
RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} badsite\.com [NC,OR]
RewriteCond %{HTTP_REFERER} anotherbadsite\.com [NC]
RewriteRule .* - [F]
Забележете, че точката е записана като ескейп последователност. Това е така, защото тук RewriteCond използва регулярни изрази (без символа ‘\’ точката ще има смисъл „които и да е символ”). Флагът [NC] („Non Case sensitive”) в края на израза задава да не се прави разлика между малки и големи букви. И накрая - последния ред от примера задава действието, което да се извърши при намиране на съвпадение в RewriteCond условията: „FAIL”. Тоест отговорът на сървъра ще бъде състояние 403 - Forbidden error. Разликата между двата примера е, че когато се изреждат RewriteCond, трябва да се постави флаг OR.
7. Блокиране на така наречените „bad bots” и „site rippers”
Какво е „bad bot”? - отговорът не е еднозначен, но общо взето за такива се смятат автоматични програми - „роботи, паяци”, които повече вредят отколкото носят популярност на сайта ви (например събирачки на e-mail адреси).
„Site ripper” е програма, която трасира вашия сайт и сваля цялото му съдържание за offline използване. И в двата случая събраната информация може да се използва както добронамерено (индексиране от търсачките например), така и за нанасяне на вреди - спам, откриване на пробиви в защитите и други. Също така и в двата случая има излишно натоварване на сървъра, което може да доведе до невъзможност за нормален достъп до сайта. Обикновено „bad bots” се блокират чрез друг специален файл - „robots.txt”, но можете да използвате и .htaccess. Въпросът е да знаете как да ги идентифицирате.
По-долу е даден код, който блокира достъпа на познатите bad bots и site rippers. Информацията е събрана от форуми по темата и разбира се няма как да е пълна, но спокойно можете да добавите този код във вашия .htaccess файл (разбира се, ако имате mod_rewrite):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]Bots
Изброените в списъка програми ще получат като отговор „403 Forbidden”, което ще намали излишния трафик и евентуално ще ускори работата на вашия сървър. Ако отделите време да прегледате вашите лог-файлове, вероятно ще намерите какво да добавите към този списък.
8. Промяна на подразбиращата се страница
Подразбиращата се страница е тази, която се зарежда, когато изпишете като адрес в браузъра вашия домейн (mySite.com, http://mySite.com, http://www.mySite.com). Подразбираща се страница може да има и всяка директория от сайта. Вероятно сте свикнали с мисълта, че това е непременно index…., но чрез .htaccess можете лесно да зададете друга страница или последователност от страници които се търсят в зададения ред:
DirectoryIndex filename.html
определя ако не е зададено друго, да се зареди filename.html.
DirectoryIndex filename.html index.cgi index.pl default.htm
определя ако не е зададено друго, да се зареди първата намерена от изброените страници. Списъка се чете от ляво на дясно. Казаното се отнася не само за основната директория, а и за всяка друга от сайта. Например ако поставим .htaccess, който съдържа горния код в поддиректория /work и напишем в браузъра „http://www.mySite.com/work/”, то търсенето ще стане във /work и ще се зареди първата съществуваща от изброените страници.
9. Пренасочване
Всеки на когото се е налагало да променя или премества сайт без да се спира работата му се е сблъсквал с този проблем - как потребителите използващи старите адреси да се пренасочат към новите. Има различни начини: чрез включване на „http-equiv” тагове, javascript или сървърно базирани програми. Но има и по-лек начин и това е чрез .htaccess. Този начин изисква минимална допълнителна работа и съответно по-малък риск от грешки.
Чрез командата Redirect в .htaccess можем да зададем в описателен вид обръщенията към определени страници или директории да се пренасочват към други URL:
Redirect /olddirectory/oldfile.html http://yoursite.com/newdirectory/newfile.html
Както виждате пренасочването се състои от 3 части: командата Redirect; адресът който трябва да се пренасочи, записан като относителен спрямо корена; и пълния URL, където трябва да се пренасочи заявката. Трите части трябва да са отделени с интервал, но задължително трябва да са на един ред. Допустимо е пренасочване и на директории:
Redirect [i]olddirectory[/i] http://yoursite.com/newdirectory/
10. Предпазване на самия .htaccess от web-достъп
Това е особено важно, когато използвате защита с пароли на отделни части от сайта. Тогава вашия .htaccess съдържа информация за местонахождението на всеки .htpasswd файл. Ако имате некоректно настроен режим за достъп или вашия сървър не е достатъчно надежден, клиетнските браузъри може да покажат съдържанието на .htaccess файла, а от там и къде се намират .htpasswd файловете. Това разбира се е крайно разсъждение, но все пак е добре да се подсигурите с още една защита: order
<Files .htaccess>
order allow,deny
deny from all
</Files>
Поставете тези редове в началото .htaccess. Това ще предпази файла от web-достъп и опита за отваряне с браузър ще доведе до грешка 403. Допълнително задайте режим за достъп до .htaccess чрез CHMOD: 644 или RW-R-R--R--.
11. Задаване на MIME типове
MIME - "Multipurpose Internet Mail Extensions" (Многоцелеви добавки към Интернет поща), обозначаващо метод за кодиране на текст и данни извън печатаемите символи от 7-битовата таблица ASCII чрез ASCII символи. Основното му предназначение е да осигури пренос на произволни данни през по-старата среда за електронна поща, откъдето идва и името му.
Какво трябва да направите за да може вашия сървър да използва подходящи драйвери за различните типове файлове, например MP3 или SWF? - просто да ги добавите като типове в .htaccess:
AddType application/x-shockwave-flash swf
AddType е команда с която се добавя MIME тип. Стрингът application е MIME типа който добавяте, а последната част е разширението на което отговаря този тип. В примера това е .swf разширение за Shockwave файлове.
По същия начин ако зададете application/octet-stream за някой тип файл, то при адресирането му ще се стартира процедура за download.
12. Предпазване от „hot linking”
„hot linking” или още известно под името „bandwidth stealing” е дирекно използване на ресурси (не html) от вашия сайт в други сайтове. Обикновено обект на такива линкове са изображения, javaScript, видео и др. Понякога това е нормално, но има случаи в които вие не бихте искали вашите файлове да се използват като част от други сайтове.
С използване на .htaccess, можете да забраните този процес. Например линковете към изображения или .css файлове да се блокират или да се пренасочват към невалидни или нарочно подправени такива. Отново ще ви е необходим инсталиран mod_rewrite. За да забраните използването на вашите .gif, .jpg, .js и .css файлове, добавете кода даден по-долу към вашия .htaccess в корена на сайта или директорията в която се намират съответните файлове:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg|js|css)$ - [F]
Заменете „mydomain.com” с името на вашия домейн. Този код ще генерира грешка при опит за използване на посочените файлове. По-забавно за вас и тъжно за тези, които без ваше разрешение използват ресурси от сайта ви ще бъде да подмените съдържанието, което ще получат, без да се генерира грешка. Следващия код показва как може да се пренасочат всички hot-links, които използват ваши .gif и .jpg изображения към алтернативно изображение - angryman.gif:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ http://www.mydomain.com/angryman.gif [R,L]
Не забравяйте да нагласите „mydomain.com” и „angryman.gif”!
Иначе казано - студен душ за горещите линкове
13. Предпазване от извеждане съдържанието на директории в браузъра
Обикновено сървърите са настроени така, че не позволяват разлистване на поддиректориите на сайта, но понякога може и да не са. Ако имате поддиректории с изображения или zip архиви и не желаете те да могат да се разглеждат чрез браузър, можете да се подсигурите като добавите:
IndexIgnore *
в .htaccess, поставен във въпросните директории. Командата забранява разлистването на всички (*) файлове от директорията.
Ако искате да скриете само определени файлове, тогава можете да ги укажете изрично:
IndexIgnore *.jpg *.gif *.png
Така ще скриете от листинга само изображенията от съответната директория. Обратно, ако сървърът забранява разлистването на директориите, но вие искате това, тогава запишете:
Options +Indexes
Бъдете много внимателни относно съдържанието на директориите за които използвате тази опция! Както можете да поставите знак плюс пред опцията, така можете да поставите и знак минус (Options -Indexes), което ще забрани разлистването. Например в поддиректория на разрешена за разлистване директория.
