165
В среде веб-программирования нередко используется файл.htaccess при хостинге сайтов под управлением сервера Apache. Это очень полезный файл, позволяющий определять неопределенные или переопределять определенные в httpd.conf или apache.conf опции для конкретного сайта иди директории этого сайта.
Файл действует на текущую директорию (где он лежит) и на все директории "ниже", т.е. все дочерние директории, если только в них не определен свой файл.htaccess.
В этой статье я изложу ряд наиболее часто применяемых возможностей этого файла. Конечно, здесь не все описано, многое Вы можете почерпнуть из просторов интернета, однако наиболее часто встречающиеся вопросы освещены.
Правила написания
Директивы файла указываются по одной на строку.
Все пути начинаются от корня сайта (не от корня файловой системы сервера!)
Например, если нужный файл на сервере лежит по пути /var/www/mysite.ru/mydir/file.html, то правильным будет путь /mydir/file.html
Если выполняется указание url, то указание происходит обязательно с использованием указания протокола.
Например, если идет перенаправление на сайт www.mysite.ru, то указывать необходимо http://www.mysite.ru
Коментарии - все, что находится после символа #
В выражениях можно использовать переменные окружения. Список наиболее часто используемых - ниже.
Наконец, при внесении изменений в файл - они сразу начинают действовать. Перезагружать ничего не надо.
Переменные окружения
Хотя и не часто, но все-же в файле.htaccess могут использоваться переменные окружения. Некоторые из них приведены ниже (спасибо сайту htaccess.net.ru):
- QUERY_STRING (параметры запроса)
- REMOTE_ADDR (IP-адрес посетителя)
- REMOTE_HOST (имя хоста посетителя)
- REMOTE_USER (имя пользователя, если он прошел аутентификацию)
- REMOTE_METHOD (метод браузера - GET или POST)
- PATH_INFO (путь к файлу веб-страницы)
- HTTP_USER_AGENT (содержимое заголовка user-agent - тип браузера)
- HTTP_REFERER (содержимое заголовка referer)
- HTTP_COOKIE (содержимое заголовка cookie)
- HTTP_HOST (имя хоста веб-сайта)
- TIME_YEAR (год, месяц и т.д.)
- TIME_MONTH
- TIME_DAY
- TIME_HOUR
- TIME_MIN
- TIME_SEC
- TIME_WDAY
- REQUEST_URI (запрашиваемый URL)
- REQUEST_FILENAME (запрашиваемый файл)
- THE_REQUEST (полностью запрос)
Регулярные выражения в.htaccess
В этом файле можно использовать регулярные выражения. Их синтаксис приведен ниже. Спасибо сайту htaccess.net.ru
В регулярном выражении можно использовать любые печатные символы и пробел, но часть символов имеет особое значение:
- Круглые скобки () используются для выделения групп символов.
- Символ ^ обозначает начало строки.
- Символ $ обозначает конец строки.
- Символ. обозначает любой символ.
- Символ | обозначает альтернативу. Например, выражения "A|B" и "(ABC|DEF)" означают "A или B" и "ABC или DEF" соответственно.
- Символ? ставится после символа (или группы символов), который может как присутствовать, так и отсутствовать. Например, выражению "jpe?g" подойдет и строка "jpg", и строка "jpeg". Пример выражения с группой символов: "super-(puper-)?site".
- Символ * ставится после символа (или группы символов), который может отсутствовать или присутствовать неограниченное число раз подряд. Например, выражению "jpe*g" подойдут строки "jpg", "jpeg" и "jpeeeeeeg".
- Символ + действует аналогично символу * с той лишь разницей, что предшествующий ему символ обязательно должен присутствовать хотя бы один раз. Например, выражению "jpe+g" подойдут строки "jpeg" и "jpeeeeg", но не "jpg".
- Квадратные скобки используются для перечисления допустимых символов. Например, выражение "" равносильно выражению "a|b|c", но вариант с квадратными скобками обычно является более оптимальным по быстродействию. Внутри скобок можно использовать диапазоны: например, выражение "" равносильно выражению "". Если символы внутри квадратных скобок начинаются с символа ^, это означает любой символ, кроме перечисленных в скобках. Например, выражение "[^0-9]+" означает строку из любых символов, кроме цифр.
- Символ \ ставится перед спецсимволами, если они нужны в своем первозданном виде. Например, выражению "jpe\+g" соответствует только одна строка "jpe+g".
- Все, что расположено правее # - считается комментарием.
Как включить
В Linux (LAMP) в конфигурации Apache использование файла.htaccess, как правило, уже разрешено. Во FreeBSD может потребоваться особо разрешить использование этого файла директивой AllowOverride в глобальной конфигурации или в конфигурации конкретного сайта.
AllowOverride All
Запрет на чтение всех файлов в директории
Доступ с определенного IP адреса
oder deny,allow
deny from all
allow from 192.168.0.1
allow from 192.168.0.2
где вместо 192.168.0.1, 192.168.0.2 указываются IP адреса, с которых пользователям можно заходить на сайт. Иначе - ошибка 403.
Запрет на доступ с определенных IP адресов
order allow,deny
allow from all
deny from 192.168.0.1
deny from 192.168.0.2
Где вместо указанных IP необходимо указывать те, доступ с которых закрыт.
Запрет доступа к файлам по маске
order allow,deny
deny from all
Вместо ext1, ext2, ext3... вставляем свои расширения. Правила запрета/доступа определяются так-же, как и для всей директории в целом.
Как частный случай - можно задать доступ для одного конкретного файла (правда, с учетом наследственности прав.htaccess - этот доступ или запрет распространится на все под-директории - т.е. на все файлы в этой директории и всех директориях ниже):
order allow,deny
deny from all
Паролирование директории
Часто используется при создании веб-сайтов, доступ к которым (или к части которых) разрешен не всем. При попытке открытия этого url веб-браузер запросит у пользователя логин и пароль.
AuthName "Введите пароль для доступа"
AuthType Basic
AuthUserFile /var/www/mysite.ru/.htpasswd
require valid-user
ВНИМАНИЕ! Заметьте, что здесь путь к файлу.htpasswd указывается от корня файловой системы сервера, не сайта!
Для использования данного способа следует иметь файл.htpasswd. Как его создать и пользовать - рассказано на этом же сайте в разделе веб. Приведем пример создания этого файла:
# htpasswd -c /var/www/mysite.ru/.htpasswd username password
Если ключ -c не указывать - утилита htpasswd не создаст файл заново, а добавить пользователя username к уже существующим.
Следует учесть, что при данном способе аутентификации логин и пароль передаются в открытом текстовом виде, потому рекомендуется использовать протокол HTTPS/SSL.
Как частный случай эту конструкцию можно использовать внутри блока
Сложное паролирование
Есть структура сайта:
/mysite.ru/A
/mysite.ru/A/B1
/mysite.ru/A/B2
Необходимо сделать так, чтобы аутентификация проводилась только при доступе к директории A всех пользователей, но при этом к директории B1 имели доступ одни пользователи, а к директории B2 - другие.
Нам понадобятся файлы.htaccess в каждой директории.
Htaccess для директории A:
AuthName "Введите пароль"
AuthType Basic
require valid-user
.htaccess для директории B1:
AuthName "Введите пароль"
AuthType Basic
AuthUserFile /var/www/mysite.ru/A/.htpasswd
require user username1 username2 username3
.htaccess для директории B2:
AuthName "Введите пароль"
AuthType Basic
AuthUserFile /var/www/mysite.ru/A/.htpasswd
require user username1 username4 username5
Вместо usernameX подставляем имена пользователей, которые имеют доступ к соответствующим директориям.
Перенаправление (редирект) на другой сайт
Redirect / http://www.anothersite.ru
Если редирект перманентный (т.е. навсегда - что очень полезно для поисковых систем), то синтаксис будет таким:
Redirect permanent / http://www.anothersite.ru
Если вместо permanent использовать слово temp - редирект будет, наоборот, временным.
Еще пример редиректа - с конкретной директории внутри сайта:
Redirect /dir2 http://www.anothersite.ru/dir2
Вместо директивы Redirect используем директиву RedirectMatch. Отличие состоит в том, что вместо указания адреса, с которого делать редирект, указывается регулярное выражение.
RedirectMatch (.*)\.gif$ http://mysite.ru/$1.png
Редиректит все обращения к.gif - на такие же по имени файлы, но с расширением.png, находящиеся по адресу mysite.ru/
Еще пример:
RedirectMatch (.*\.jpg)$ http://mysite/$1
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.old_site\.ru$
RewriteCond %{HTTP_HOST} ^old_site\.ru$
RewriteRule ^(.*)$ http://new_site.ru/$1
Показ разных страниц в зависимости от IP-адреса пользователя
SetEnvIf REMOTE_ADDR 192.168.0.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /another_page.html
Вместо 192.168.0.1 вставляем свое значение.
Подмена стартовой страницы
DirectoryIndex another_file.php
По-сути, здесь мы подменяем указываемую в httpd.conf или apache.conf файле директиву DirectoryIndex.
Замещение страниц ошибок
ErrorDocument 403 /error403.html
ErrorDocument 404 /error404.html
Таким образом, при наступлении, например, ошибки 404, браузер не будет отображать свою страницу, а попытается загрузить стилизованную страницу с сайта.
Сделать запрет отображения списка файлов в директориях без index-файла
Options -Indexes
Таким образом пользователь не сможет отобразить контент директории, где нет индексного файла (а в директории, где есть индексный файл - он не может этого сделать по-умолчанию).
Указывание отображаемой кодировки
Можно указать брайзеру - в какой кодировке ему передаются файлы. Это снизит вероятность ошибки в автоматическом определении кодировки, если файлы передаются в одной, а браузер почему-то начинает их отображать в другой.
AddDefaultCharset windows-1251
Указывание автоконвертации кодировки загружаемых файлов
При загрузке на сайт файлов они будут автоматически переконвертированы в указанную кодировку.
CharsetSourceEnc koi8-r
Добавление обработчиков MIME
AddType "text/html" .myext
AddType "application/x-rar-compressed" .rar
Таким образом мы можем добавить нашему сайту директивы, не описанные в глобальном конфиге Apache.
Блокировка определенных User-Agent (веб-браузеров, ботов и роботов)
Вот кусок файла.htaccess, в котором заблокированы несколько User-Agent (веб-браузеров; ботов, на самом то деле).
SetEnvIfNoCase User-Agent "^Titan" bad_bot
SetEnvIfNoCase User-Agent "^Wget" bad_bot
SetEnvIfNoCase User-Agent "^SiteSnagger" bad_bot
SetEnvIfNoCase User-Agent "^WebAuto" bad_bot
SetEnvIfNoCase User-Agent "^NetAnts" bad_bot
SetEnvIfNoCase User-Agent "^WebZip/4.0" bad_bot
SetEnvIfNoCase User-Agent "^httplib" bad_bot
Order Allow,Deny
Allow from all
Deny from env=bad_bot
Список "плохих" User-Agent здесь очень мал и приведен только как пример.
Настройки PHP
Помимо переменных httpd.conf и apache.conf нам также может пригодиться изменение заданных в php.ini значений настроек php. .htaccess файл позволяет сделать и такие приятные вещи. Для этого используется директивы php_value и php_flag.
Разница между php_value и php_flag: первая директива присвает конкретное значение настройке:
php_value
а вторая - включает или выключает boolean-настройку:
php_flag
ВНИМАНИЕ! Вы не можете использовать php_admin_flag и php_admin_value в файле.htaccess!
Например, код
php_flag magic_quotes_gpc 0
php_flag magic_quotes_runtime 0
выключит автоматическое экранирование данных в PHP (выключит MagicQuotes), а код
php_value memory_limit 64M
переопределит значение максимального количества памяти, выделяемого для сайта.
Эти значения переопределяют определенные в php.ini файле величины или определяют их, если таковые не были установлены администратором хостинг-сервера. Весь список php-настроек здесь приводить смысле нет - его можно почерпнуть из документации к php нужной Вам версии.
Модуль Rewrite
В состав сервера Apache входит модуль Rewrite. Несмотря на то, что он используется в файле.htaccess, его мы описывать сейчас не будем, т.к. это отдельная тема, достойная отдельной статьи.
Актуально для: Apache 2.x
Это далеко не все, что можно делать с файлом.htaccess. На просторах интернета очень много специфичных примеров, здесь же собраны наиболее часто необходимые примеры.
Файл htaccess - настройка и примеры использования - 4.1 out of 5 based on 18 votes
Файл htaccess позволяет производить конфигурирование и переопределение настроек веб-сервера Apache и подобных ему серверов. С его помощью можно установить разрешения и параметры для работы сервера у определенных пользователей хостинга и даже на отдельных папках определенного пользователя.
Чаще всего его применяют для создания 301 редиректа со старых URL на новые, переназначение типов файлов, управляемый доступ к каталогом и многого другого. Благодаря файлу htaccess не нужно обращаться к основному файлу конфигураций и затрагивать работу сервера целиком.
Что собой представляет файл htaccess и для чего используется
Как уже упоминалось, htaccess используется для установки некоторых параметров серверов Apache и других серверов. Несмотря на большое и странное расширение, настройка файла.htaccess производится путем открытия и изменения его содержимого с помощью любого текстового редактора.
Файл htaccess был придуман специально для того, чтобы можно было предоставить возможность менять конфигурацию сервера каждому пользователю, затрагивая только свой собственный сайт, а не весь сервер целиком. Всем известно, что основные директивы конфигурации Apache находятся в файле httpd.conf. Однако у большинства пользователей, а если говорить о виртуальном хостинге, то у всех пользователей, нет возможности получить доступ к нему и прав на модификацию, так как это действие будет распространяться на всех.
Файл с расширением htaccess часто называют динамическим. Это обусловлено тем, что сервер должен каждый раз обращаться к нему, когда потребуется выполнить запрос к содержащему его каталогу. Пожалуй, это существенное преимущество, так как изменения, внесенные пользователем в файл, сразу вступят в силу без потребности перезагрузки сервера. В случае внесения изменений в главный конфигурационный файл перезапуск сервера – обязательное условие вступления их в силу.
Безусловно не все так гладко, как хотелось бы, так как использование htaccess немного сказывается на производительности сервера, тем нем менее, в случае закрытого доступа к основному конфигурационному файлу, данный способ является самым простым и удобным методом для изменения параметров.
Некоторые особенности использования htaccess:
1. В нем можно переопределить большое количество директив, прописанных в главном файле httpd.confg
2. Если расположить htaccess-файл в корневой каталог, он распространится на весь сайт (исключения составят только те каталоги, в которых расположен собственный конфигурационный файл, и каталоги, расположенные ниже в древовидной структуре)
3. Разместить htaccess-файл можно в любой каталог, а его директивы будут применены ко всем подкаталогам
4. Htaccess не доступен пользователю для просмотра из браузера, так как относится к категории «системные».
Таким образом, с помощью htaccess пользователь получает гибкость в настройке собственного сервера и может применять следующие параметры:
- Директивы простого перенаправления (редирект);
- Директивы сложного перенаправления (mod_rewrite);
- Индексные страницы;
- Обработка ошибок;
- Определение кодировки;
- Управление доступом к директориям и файлам;
- Паролирование директорий;
- Опции PHP.
Примеры наиболее частого использования файла htaccess
Сейчас мы рассмотрим самые распрострнные рабочие варианты использования htaccess для настройки сайта.
Прежде чем мы приступим обратите внимание на следующие моменты:
2. Для того, чтобы создать новый файл с расширением htaccess, необходимо, открыть блокнот или другой текстовый редактор, написать код, сохранить файл, указав расширение.htaccess (точка в переди). Затем остается забросить его в директорию, для которой он предназначался.
3. Синтаксис.htaccess
Пути к файлам (директориям) указываются от корня сервера.
DirectoryIndex /home/st5155/www/data/home.html
В случае настройки файла htaccess лежащего в корневой папке сайта, пути указываются от корня этой папки.
DirectoryIndex /home.html
Домены записываются с указанием протокола http:// или https://
Redirect / http://vash-sait.ru
Файл имеет название именно "точка" htaccess.
Для создания закомментированной строчки используйте знак #.
Редактировать файл удобнее всего при помощи редактора AkelPad, входящего в состав Total Commander, достаточно его выделить и нажать F4.
Простое перенаправление - директива Redirect
1. Осуществление перенаправления на новые страницы сайта
Если на сайте были перемещены страницы на новые адреса, то пользователь или поисковый робот, обратившись по старому адресу, наверняка их не увидит. Чтобы склеить старый и новый адреса страницы можно применить простой 301 редирект. Для этого в файле конфигурации htaccess необходимо прописать следующий код:
Redirect 301 /staraya.html http://vash-sait.ru/novaya.html
2. Приведение фидов к общему формату
Раньше использовались различные форматы фидов, такие как: Atom, RSS, Rdf. Сегодня RSS является основным и самым популярным среди них, поэтому можно позаботиться о том, чтобы другие форматы перенаправлялись в один. Для этого также используется файл htaccess и следующий код:
Сложное перенаправление - директива RewriteRule
1. Перенаправление домена с www на без www.
Очень часто приходится использовать 301 редирект в htaccess для склеивания доменов с www и без www. Раньше поисковые системы считали такие адреса совершенно различными и смотрели на них как на разные сайты. Сегодня задача по склейке возлагается на поискового робота, но никогда не лишним будет указать корректное зеркало. К тому же, у самих не будет никакой путаницы.
Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} ^www.vash-sait\.ru$ RewriteRule ^(.*)$ http://vash-sait.ru/$1
2. Перенаправление посетителей на разные старницы в зависимости от IP-адреса посетителя.
В htaccess имеется возможность указать на какую страницу, будет перенаправлен пользователь с конкретным IP-адресом. Например, перенаправление посетителей с ip адресом 183.11.101.1 на страницу kontakt.html
SetEnvIf REMOTE_ADDR 183.11.101.1 REDIR="redir" RewriteCond %{REDIR} redir RewriteRule ^/$ /kontakt.html
3. Перенаправление в случае обновления веб-ресурса
Во время тестирования или обновления ресурса пользователь не сможет попасть на сайт. Однако будет неправильным не предупредить его об этом. В.htaccess можно прописать код, который будет перенаправлять пользователя на информационную страницу, описывающую сущность проблемы (причины, сроки и т. д.).
RewriteEngine on RewriteCond %{REQUEST_URI} !/info.html$ RewriteCond %{REMOTE_HOST} !^14\.124\.354\.80 RewriteRule $ http://vash-sait.ru/info.html
Где 14.124.354.80 - заменить на свой IP адресс.
4. Защита от хотлинков
Не для кого не секрет, что сегодня все чаще воруют информацию с сайтов. Иногда только текстовую, а иногда и вместе с графическими изображениями. И каждый раз когда на сторонний сайт будет приходить посетитель эти изображения будут грузится с вашего хостинга создавая нагрузку и сжигая трафик. Чтобы это предотвратить добавляем следующий код:
RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://([ -a-z0-9] \.)?vash-sait\.ru RewriteRule \.(gif|jpe?g|png)$ -
В приведенном выше примере на сайте грузящем изображение будет появляться ошибка 403, если желаете чтобы вместо картинки отображалась определенная картинка, то последнюю строку замените на следующую:
RewriteRule \.(jpg|png|gif)$ http://vash-sait.ru/images/imageinfo.jpg
5. Перенаправление на безопасное https-соединение
В.htaccess можно настроить перенаправление на безопасное https соединение, чтобы все пользователи работали только через данный протокол, гарантирующий безопасность и надежность передачи данных между сервером и клиентом.
RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
6. Автоматическая подстановка слеша в конце адреса.
Очень распространены ситуации, когда URL-адрес, заканчивается именем каталога: http://vash-sait.ru/images/raznoe
Apache самостоятельно может исправить ошибку и сделать 301-е перенаправление, добавив к ссылке недостающий слеш. Таким образом, пользователь не ощутит никакой разницы и получит в ответ необходимую страницу. Но на выполнение такого действия понадобится в два раза больше времени. Следующий код всегда будет добавлять / в конце адреса.
RewriteCond %{REQUEST_URI} /+[^\.]+$ RewriteRule ^(.+[^/])$ %{REQUEST_URI}/
7. Блокировка пользователей пришедших с определенного сайта
Если владелец сайта не хочет, чтобы его ресурс посещали пользователи, зашедшие с определенного домена и требуется им закрыть доступ - htaccess также готов помочь. Вы можете перекрыть трафик с определенных сайтов используя страницу 403 или «запрет доступа». Полезна данная настройка тогда, когда на ваш сайт появились ссылки с сайтов с запрещенным контентом и по ним идет трафик на ваш сайт.
Индексные страницы - директива DirectoryIndex
1. Изменение индексной старницы загружаемой по умолчанию
Обычно по умолчанию индексными страницами является index.htm, index.php или index.html, при обращении к директории сайта сразу происходит поиск данных файлов. Но при необходимости можно переопределить индексную страницу на любую другую. Подобная задача также решается с использованием htaccess-файла.
DirectoryIndex mypage.html
Имеется возможность указать две и более страницы. Стоит учитывать, что они будут отыскиваться в той последовательности, в которой перечислены в конфигурационном файле за директивой DirectoryIndex.
DirectoryIndex index.shtml index3.php index.html index.htm
Обработка ошибок - директива ErrorDocument
1. Пользовательская страница ошибок
Несмотря на тот факт, что многие на сайтах до сих пор пользуются стандартной страницей ошибок 404, она вряд ли удовлетворит пользователя, который не получил ожидаемого результата и вместо него увидит непонятную для него информацию. Необходимо предложить страницу, которая будет соответствовать основному стилю, на которой будет выводиться более подробная информация о причинах неудачного выполнения запроса. Для этого можно указать в htaccess какой файл грузить вместо стандартной страницы ошибки 404.
ErrorDocument 404 "/404.html"
2. Создание своих страниц с описанием ошибок
Для тех, кто устал от привычных страниц, выводящих описание ошибок, произошедших на сайте, предоставляется возможность воспользоваться своими собственными заготовками. Нужно лишь самому сверстать несколько файлов с разрешением *.html, с необходимым содержимым и внести запись в htaccess-файл.
ErrorDocument 401 /errors401.html ErrorDocument 403 /errors403.html ErrorDocument 404 /errors404.html ErrorDocument 500 /errors505.html
Чтобы вы знали что помещать в каждую из страниц ошибок, кратико опишем их значения.
- 401 - Требуется авторизация (Authorization Required)
- 403 - пользователь не прошел аутентификацию, запрет на доступ (Forbided)
- 404 - запрашиваемый документ (файл, директория) не найден (Not Found)
- 500 - внутренняя ошибка сервера - ошибка скрипта или ошибка в синтаксисе файла.htaccess - (Internal Server Error)
Определение кодировки
1. Определение кодировки, в которой сервер "отдает" файлы
Чтобы у пользователя на дисплее монитора не выводились непонятные для него символы, из которых не представляется возможности прочесть слова, необходимо указать корректную кодировку. Даже при отсутствии тега < Мета http-equiv = "Content-Type"> текст на странице будет всегда корректным и поможет в этом снова htaccess-файл.
AddDefaultCharset UTF-8
2. Определение кодировки на загружаемые файлы
Подобная ситуация может возникнуть в том случае, когда пользователь загружает на сервер файл и его содержимое может быть перекодировано. Чтобы использовалась требуемая кодировка htaccess должен содержать код, указывающий что все загружаемые файлы должны будут открываться с кодировкой UTF-8.
CharsetSourceEnc UTF-8
Управление доступом к директориям и файлам
1. Запретить доступ ко всем файлам
Самый простой способ запретить просматривать файл – установить пароль, но не всегда этого достаточно. В некоторых случаях у пользователя не должно быть прав на просмотр любых файлов или каталогов (например нужно заблокировать системные каталоги, изменения в которых могут усугубить работу сервера). В htaccess-файле прописывается отрывок кода, лишающий всех привилегий пользователей.
2. Разрешить доступ с определенного IP
- Tutorial
Google выше ранжирует сайты, которые загружаются быстрее. - Если на eBay или Amazone увеличить время загрузки страниц на 9% они теряют 1% прибыли. - Сделать свой сайт быстрее, чтобы сэкономить на клиентском трафике и на числе обращений к серверу.
.htaccess - наш герой
Профессионалы знают, что такое htaccess.Тем кто собираются уйти с народ.ру на php-хостинг только предстоит узнать, что это такое.
Те кто только что установил свои первые jooml"у или wordpress срочно должны узнать о нашем герое - htaccess
Зачем нам.htaccess ?
Представьте, что вы купили себе хостинг и кажется, почти обрели счастье. Но однажды (а может быть дважды, а может и трижды) ваш сайт перестает отвечать на запросы. Начинает медленно грузиться и вообще вести себя странно. А виртуальный хостинг это такая хитрая штука, что помимо вашего сайта на этом сервере находится ещё два десятка других сайтов. Все они разные по мощности, организованности и трафику. И когда ваш сосед по случайности, а может и умыслу запускает на своем хостинге сложные или избыточные в алгоритмах скрипты, это отзывается и на вас.Или другой пример. Скажем ваш ресурс начинает набирать популярность, но переезжать на выделенный сервер ещё рано, а мощностей VPS уже не хватает. Вас очень может выручить htaccess.
А ещё htaccess может решить некоторые вопросы с безопасностью вашего сайта.
Хочу идеальный.htaccess !
Оказывается в интернете много различной противоречивой информации относительно того как использовать.htaccess. Пришлось долго и нудно экспериментировать, чтобы понять что истинно, а что ложно. В большинстве случаев авторы советов в своих блогах забывают упомянуть, что для работы определенных условий нужен тот или иной модуль Апача.Впрочем хватит слов, пора к делу. Попробуем создать почти идеальный.htaccess
1. Первой строкой задаем основные опции:
Использовать опции очень удобно, когда у вас нет доступа к конфигурированию Апача или нужны разные настройки Апача для разных сайтов на одном сервере.
Опция -ExecCGI запрещает запуск CGI скриптов. Лучше разрешить только для конкретных папок. Повысит безопасность.
Опция -Indexes запрещает показывать содержимое каталогов, если в них нет индексного файла. На виртуальном хостинге обычно включена по умолчанию. Изменив минус на плюс +Indexes можете наоборот разрешить просмотр содержимого каталога (или каталогов).
Опция -Includes запрещает SSI. Если не знаете, что это - запрещайте (Можно поЯндексировать(!) по запросу Server Side Include если хотите узнать об этом побольше). Можно использовать опцию IncludesNOEXEC, которая разрешит использовать SSI без запуска скриптов.
Опция +FollowSymLinks позволяет использовать символические ссылки на файлы или каталоги, не находящиеся в пределах корня вашего сайта.
Примечание
Вы можете использовать htaccess с разными настройками для разных каталогов. В корне сайта вы можете объявить -Indexes, а в избранных каталогах создать ещё один файл.htaccess и в нем объявить +Indexes. Помните, что действие опций htaccess распространяет сверху вниз по дереву каталогов до самой глубокой вложенности, пока не будут отменены другим htaccess.
Необязательно полностью перечислять все опции в дочерних.htaccess если они не изменяются. Достаточно указать (переназначить) только те опции и директивы, которые изменяются. Остальные опции также унаследуются от родителя.
Пример
Скажем, у вас есть вот такой путь /site/folder_one/subfolder/other/
В файле /site/.htaccess вы указываете:
Options -Indexes
Allow from all
В файле /site/folder_one/.htaccess указываете:
Deny from all
В файле /site/folder_one/subfolder/.htaccess указываете:
Options +Indexes
Allow from all
Получиться вот что:
В папке site будут показываться файлы любого содержания, если только к ним напрямую обратиться. Или индексный файл, если не явного обращения к одному из файлов. В случае отсутствия индексного файла получена 403 ошибка.
К папке folder_one доступ закрыт. Даже если знать имя файла и набрать его в адресной строке в ответ сервер вернет ошибку 403.
Папка subfolder разрешена для обращений по прямому адресу или же в случае отсутствия индексного файла покажет содержимое каталога. Эти же права распространяться и на папку other.
Если убрать файл,htaccess из папки folder_one, то она унаследует права от родительской site.
2. Немного SEO (куда же без него)
Обязательно не забыть про условие
В данной части пользы больше для SEO. Модуль rewrite как следует из его названия занимается перенаправлениями (привет Кэпу) .
В этой части файла мы указали две склейки: мы склеили ваш_сайт и www.ваш_сайт Даже если пользователь наберет ваш сайт без WWW его перебросить 301 редериктом на www.ваш_сайт .
А также мы избавились /index.php в строке запроса. Если пользователь наберет www.ваш_сайт/index.php его перебросит (снова 301 редериктом) на www.ваш_сайт .
Теперь поисковики не будут путаться между www и не будут дублировать главную страницу в результатах индексирования вашего сайта. Гуглим СЕО склейки домена, если не понимаете зачем это нужно.
3. Кто в папке главный?
Если у вас папке есть файлы index.html и index.php (не знаю, зачем и кому такое было нужно, но не раз видел такое) то как указать серверу кто их них более индексный?
DirectoryIndex index.php
А ещё можно там указать скажем roosso.php и тогда набрав в строке запроса адрес сайт.бла/бла/бла/ вы увидете не index, а roosso
4. Ещё настройки…
Первая строчка устанавливает часовой пояс. Например в Apache 2.22.22 был баг связанный с этой опцией. Функции времени в php не работали, пока не установишь часовой пояс.
Вторая строка это подпись сервера. Вы их не раз видели на всяких системных страницах типа 500ой ошибки или 403ей. Обычно там какая-нибудь техническая информация и почта вебмастера. Я предпочитаю даже в таких мелочах скрывать данные о софте на сервере. Коллеги параноики меня поддержат.
Угадайте, что делает третья строка?
5. Когда нет доступа к php.ini
С помощью.htaccess мы также можем управлять рядом настроек PHP. На виртуальном хостинге, как правило, нет возможности изменять настройки php.ini. Чаще всего этого и не требуется. Но все же есть ряд опций контроль над которыми может нам быть полезен. Например, увеличить лимит на загрузку файлов, или лимит передачи данным методом POST.
Первая строчка разрешить загружать файлы размером до 32 Мегабайт. По умолчанию в php обычно это значение 8 или 16 мегабайт.
Второй строкой разрешаем постинг объемом до 10 мегабайт. По умолчанию это значение обычно 2 Мегабайта.
Третья строка устанавливает кодировку по используемую вашими скриптами. По своей сути она дублирует строку: «AddDefaultCharset UTF-8». Но я чаще прибегаю к установке кодировки именно через php.
Четвертой строкой изменяем лимит времени выделенный на выполнение скрипта. По умолчанию он обычно равен 30 секундам. Но иногда для выполнения каких нибудь сложных обработок требуется больше времени.
6. Типы файлов. Ловкость рук и ни какого мошенничества.
В моей практике случалось пару раз, что после какого либо обновления провайдером софта, слетали типы файлов. Хотя такое редко. За 10 лет, всего два случая. Но иногда мне нужно было заставить html работать как php. А иногда требуется научить апач различать типы файлов, которые ему неизвестно. (Как оказалось Апачу вообще мало что известно из редких типов файлов.) В такой ситуации нас спасет следующий код:
AddHandler application/x-httpd-php .html AddHandler cgi-script .pl .py .jsp .asp .htm .shtml .sh .cgi AddType application/x-javascript .js AddType text/css .css AddType text/xml .xml AddType application/octet-stream .doc .mov .avi .pdf .xls # ForceType application/x-httpd-php
Первая строчка позволит нашим php файлам иметь расширение html, но выполняться как php. Полезно бывает во многих случаях. А в старые добрые когда поисковики индексировали ЧПУ лучше, такая строчка всегда приходила на выручку.
Мы можем переназначить, добавить или подменить любые типы файлов под удобные нам разрешения.
Интересный трюк
Кстати, вы можете легко написать к примеру вот такую строку:
AddHandler application/x-httpd-php .i
Потом переименовать все ваши файлы, изменив расширение на.i (не забыв конечно про ссылки) и адреса файлов у вас на сайте будут не сайт.мой/index.php?uri а сайт.мой/index.i?uri
Например я пишу
AddHandler application/x-httpd-php .roosso
и создаю в корне своего сайта файл alex.roosso внутри обычный php код. Это вроде как страница обо мне любимом. И в адресной строке она будет выглядеть как www.black-web.ru/alex.roosso (ссылка рабочая, можете посмотреть что это так).
Второй строкой указано, какие расширения файлов должны выполняться как cgi скрипты.
Третья, четвертая и пятая строки, на всякий случай уточняют мим-тип файлов с разрешением css, js, xml. Не путайте с присвоением заголовка в ответе сервера на запрос, как это сделано в первых двух строках.
Шестая строчка это участка, нужна если на вашем сайте есть скачиваемый для пользователей контент. Если добавить эту строку, то при обращении к данным файлам им будет предлагаться скачать их на компьютер, а не как это сейчас в современным браузерах куча плагинов, которые даже word открывают в браузере.
Седьмую строку я закомментировал. Это строчка в принудительно-добровольном порядке, будет все файлы с вашего сервера запустить как php. Её лучше использовать лишь в отдельных папках, при необходимости.
7. Знают взрослые и дети, что архивы меньше весят…
Полезно, когда ваши страницы загружаются быстрее. Поэтому люди и придумали архивировать файлы. А потом они ещё подумали и решили, что архивировать можно и страницы на сайтах и картинки. Причем делать это незаметно для пользователя, но существенно снижать трафик и ускорять загрузку страниц. Волшебные слова прозвучали, теперь обсудим, как это можно сделать.
У Апача есть два модуля сжатия. Оба не являются модулями по умолчанию, поэтому необязательно могут присутствовать у вашего провайдера. Но как показала практика у 99% провайдеров один из них стоит. Наиболее распространен mod_deflate. Чтобы его с помощью сжимать весь контент на вашем сайте добавьте в.htaccess следующие строки:
Как видите мы должны перечислить mime type файлов, которые следует подвергать сжатию. Сюда можно добавить и видео и картинки, но толку это даст мало. Потому что jpeg или gif уже сами по себе являются сжатыми форматами. Также как avi или flv. Вы фактически нечего не выиграете указав их.
Второй менее популярный модуль это mod_gzip, Чтобы включить сжатие с его помощью добавьте вот такие строчки:
Данный модуль умеет работать с масками, что несомненно большой плюс. Да и синтаксис у него куда более гибкий чем у предыдущего. Но используют его реже. А по сжатию я даже не берусь судить, который из модулей лучше. Я сильной разницы не заметил при тестах.
8. А ещё быстрее можно?
Можно. Если применить кеширование страниц. У кеширования есть и плюсы и минусы, поэтому подходить к этому вопросу надо подготовившись. Для динамически обновляющегося сайт каждый 2-3 минуты, например популярного форума, нужно учесть, что пользователь должен видеть актуальную информацию. Но у любого сайт есть контент, который более или менее статичен. Например те же картинки, или файлы стилей. Поэтому нам потребуется по разному использовать кеширование различного содержимого на сайте. В html разметки мы всегда можем использовать meta теги. И через php мы может устанавливать заголовки ответа сервера. Остается вопрос, как быть с css, js, image и т.д. и т.п.
Помочь нам в этом могут два модуля: mod_headers и mod_expires которые могут установить заголовки в ответ сервера и подсказать вашему браузеру, что и как нужно кешировать. Один из модулей обычно стоит у провайдера, но как и в случае с любым модулем, который не входит в стандартную сборку Апача, 100% гарантии никто вам не даст. Поэтому снова во избежание 500й ошибки указывает условия для каждого из модулей.
Вот такой синтаксис у mod_headers. Думаю по комментариям ясно что к чему.
В данной секции я отключил кеширование php файлов. Хотя по моему мнению небольшой временной интервал кеширования им не повредит. 5-30 секунд, это интервал времени, за который мало что меняется. А многие пользователи любят пользоваться клавишей back (вернуться назад). Чтобы не загружать им страницу второй раз, а подхватить её из кеша, разумный интервал кеширования все же уместен.
Во второй секции где идут условия для mod_expires я именно так и делаю - для php ставлю небольшой интервал кеширования.
9. Правила вежливого тона…
В процессе модернизации своего сайта, мы часто оставляем хвосты ввиде ссылок, которые ведут на страницы, которые мы удалили. Иногда такие ссылки идут с других сайтов или из поисковых систем. Чтобы не терять пользователей вежливым тоном считается иметь собственные страницы для различного типа ошибок. Включая даже ошибки сервера. Например стандартное сообщение о 500й ошибки очень скучное и мрачное, и вряд ли вызовет у пользователя желание посетить вашу страницу ещё раз. Но в htaccess есть приемы, которые могут сделать даже эту страницу приветливей.
# Bad Rquest
ErrorDocument 400 /400.html
# Authorization Required
ErrorDocument 401 /401.html
# Forbidden
ErrorDocument 403 /403.html
# Not found
ErrorDocument 404 /404.html
# Method Not Allowed
ErrorDocument 405 /405.html
# Request Timed Out
ErrorDocument 408 /408.html
# Request URI Too Long
ErrorDocument 414 /414.html
# Internal Server Error
ErrorDocument 500 /500.html
# Not Implemented
ErrorDocument 501 /501.html
# Bad Gateway
ErrorDocument 502 /502.html
# Service Unavailable
ErrorDocument 503 /503.html
# Gateway Timeout
ErrorDocument 504 /504.html
Для 400-х ошибок можно использовать и динамические страницы на php. А вот для 500 лучше сделать на html и js. Это часть ошибок обычно связана с ошибками сервера (в большинстве случаев) и php или cgi как правило в такой ситуации не работают.
Если вам лень делать столько страниц устанавливайте страницей ошибок главную страницу своего сайта или карту сайта.
Все это вы делаете исключительно для людей. Поисковым роботам плевать на то есть у вас страницы ошибок или нет. Они видят ответ сервера с кодом ошибки и блокируют вашу страницу в поиск. Так что имейте ввиду, это не панацея. Это лишь вежливость к вашей аудитории и имидж вашего сайта.
10. Подведем итог
Знатоки понимают, что в этой статье описано далеко не все. Я коснулся здесь лишь поверхности «айсберга». На самом деле возможности.htaccess куда много обширней, чем описано в статье. Но я и не преследовал целью перевести манаул по htaccess на русский язык. Всего чего я хотел это создать небольшой костяк файла.htaccess для тех, кто только приступил к изучению данного вопроса, чтобы сэкономить их время на поисках информации по сети.
В результате всех манипуляций у нас должен был получить файл следующего содержания:
Options All -ExecCGI -Indexes -Includes +FollowSymLinks
11. Послесловие.
Я старался не спешить в написании статьи и на это ушли почти сутки. Но все же где то я мог допустить ошибки в орфографии или пунктуации. Прошу не казнить, а миловать. А лучше писать в личку, чтобы я поправил ошибки.
И напоследок для любителей экспериментов несколько строк.htaccess. Сужу по своему опыту - на практике знания усваиваются лучше чем в теории.
Apache
- самый распространённый HTTP-сервер
. Распространяется бесплатно,
включая исходные тексты.
Поддерживаются сценарии на CGI
(включая FastCGI
), PHP
, Perl
, Java
. Аутентификация
- базовая
, message-digest
, TLS
(SSL)
. С апреля 1996 это самый популярный HTTP-сервер
в Интернете,
в августе 2007 года он работал на 51% всех веб-серверов.
.htaccess
- файл дополнительной конфигурации веб-сервера Apache
, а также подобных ему серверов.
Позволяет задавать большое
количество дополнительных параметров и разрешений для работы веб-сервера у отдельных пользователей (а также на
различных папках отдельных пользователей),
таких как управляемый доступ к каталогам
, переназначение типов файлов
и т.д., не предоставляя доступа
к главному
конфигурационному файлу, т.е. не влияя на
работу всего сервиса целиком.
.htaccess является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги. Возможность использования .htaccess присутствует в любом каталоге пользователя.
Файл .htaccess может быть размещен в любом каталоге сайта. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов .htaccess ).
Директивы .htaccess
предоставляют пользователю широкий выбор возможностей по настройке своего сайта,
среди которых:
|
|
Список всех доступных директив можно посмотреть .
Описываются предпочтения клиента относительно типа документа.
IP-адрес посетителя.
Адрес посетителя в нормальной форме - например, rt99.net.ru
.
Имя удаленного пользователя. Имеет формат имя.хост, например, kondr.www.rtt99.net.ru
Тоже, что и REMOTE_IDENT, но содержит только имя. Пример: kondr
Позволяет определить тип запроса (GET или POST). Должен обязательно анализироваться, т.к.
определяет дальнейший способ обработки информации.
Полный путь к веб-странице на сервере.
Содержит в себе все, что передавалось в скрипт.
Содержит строчку, переданную в качестве запроса при вызове CGI
скрипта.
Используется для идентификации пользователя
Cодержит путь к корневой директории сервера.
Почтовый адрес владельца сервера, указанный при установке.
IP-адрес вашего сайта.
Порт, на котором работает Apache.
Версия HTTP
протокола.
Название сервера, например, Apache/1.3.2 (Unix)
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
Переменные, предназначеные для работы со временем в разных форматах.
Это версия API
модуля Apache
(внутренний интерфейс между сервером и модулем) в
текущей сборке сервера, что определено в include/ap_mmn.h
.
Полная строка HTTP
-запроса, отправленная браузером серверу (т.е., «GET /index.html
HTTP/1.1»
).
Она не включает какие-либо дополнительные заголовки отправляемые браузером.
Ресурс, запрошенный в строке HTTP-запроса.
Полный путь в файловой системе сервера к файлу или скрипту, соответствующему этому запросу.
Условие - это шаблон условия, т.е. какое-либо регулярное выражение, применяемое к текущему экземпляру
"Сравниваемая Строка", т.е. "Сравниваемая Строка" просматривается на поиск соответствия Условию.
Помните, что Условие это perl
-совместимое регулярное выражение с некоторыми дополнениями:
Все эти проверки также могут быть предварены префиксом восклицательный знак ("!") для инвертирования их значения.
RewriteEngine
включает или выключает работу механизма преобразования. Если она установлена в положение
off
, этот модуль совсем не работает.
Заметьте, что по умолчанию настройки преобразований не наследуются. Это означает, что вы должны иметь RewriteEngine
on директиву для каждого
виртуального хоста, в котором вы хотите использовать этот модуль.
Синтаксис RewriteEngine
выглядит следующим образом:
Используйте для комбинирования условий в правилах OR
вместо AND
. Типичный пример - перенаправление
запросов на поддомены в отдельные каталоги.
Для выдачи разных сайтов для разных браузеров, согласно «User-Agent:»
заголовку запроса,
Вы можете использовать следующие директивы:
В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления в качестве третьего аргумента директивы RewriteRule . Флаги - это разделённый запятыми следующий список флагов:
"redirect|R [=code]"
(вызывает редирект)
Префикс в Подстановке вида http://thishost[:thisport]/
(создающий новый URL
из какого-либо
URI
)
запускает внешний редирект (перенаправление). Если нет никакого кода, в подстановке ответ будет со
HTTP
статусом 302 (ВРЕМЕННО ПЕРЕМЕЩЕН). Для остановки процесса преобразования
вам также нужно написать флаг "L"
.
"forbidden|F [=code]"
(делает URL запрещенным)
Это делает текущий URL
запрещённым, например, клиенту немедленно отправляется ответ
с HTTP
статусом 403 (ЗАПРЕЩЕНО). Используйте этот флаг в сочетании с соответствующими
RewriteConds
для блокирования URL
по некоторым критериям.
"gone|G [=code]"
(делает URL «мёртвым»)
Этот флаг делает текущий URL
«мертвым», т.е., немедленно отправляется HTTP
ответ
со статусом 410 (GONE
). Используйте этот флаг для маркировки «мертвыми» несуществующие более
страницы.
"proxy|P [=code]"
(вызвает прокси)
Этот флаг помечает подстановочную часть как внутренний запрос прокси и немедленно
(т.е. процесс преобразования здесь останавливается) пропускает его через прокси-модуль.
Используйте этот флаг для того, чтобы добиться более мощной реализации директивы ProxyPass
,
интегрирующей некоторое содержимое на удаленных серверах в пространство имён локального сервера.
"last|L [=code]"
(последнее правило)
Остановить процесс преобразования на этом месте и не применять больше никаких
правил преобразований. Используйте этот флаг для того, чтобы не преобразовывать
текущий URL
другими, следующими за этим, правилами преобразований.
"next|N [=code]"
(следуюший раунд)
Перезапустить процесс преобразований (начав с первого правила). В этом случае URL
снова
сопоставляется неким условиям, но не оригинальный URL
, а URL
вышедший из последнего
правила преобразования. Используйте этот флаг для перезапуска процесса преобразований, т.е.
безусловному переходу на начало цикла.
"chain|C [=code]"
(связь со следующим правилом)
Этот флаг связывает текущее правило со следующим (которое, в свою очередь, может
быть связано со следующим за ним, и т.д.). Это имеет следующий эффект: если есть
соответствие правилу, процесс продолжается как обычно, т.е. флаг не производит
никакого эффекта. Если правило не соответствует условию, все следующие, связанные
правила, пропускаются.
"type|T=MIME-тип [=code]"
(принудительно установить MIME тип)
Принудительно установить MIME-тип
целевого файла в MIME-тип
. К примеру, это можно
использовать для имитации mod_alias
директивы ScriptAlias
, которая принудительно
устанавливает для всех файлов внутри отображаемого каталога MIME
тип
равный «application/x-httpd-cgi»
.
"nosubreq|NS [=code]"
(используется только в случае не внутреннего подзапроса)
Этот флаг дает команду механизму преобразований пропустить директиву, если текущий подзапрос
является внутренним подзапросом. К примеру, внутренние подзапросы в Apache
происходят тогда,
когда mod_include пытается получить информацию о возможных файлах по умолчанию для каталогов
(index.xxx). При подзапросах это не всегда полезно и даже иногда вызывает проблему в работе
набора директив преобразований. Используйте этот флаг для исключения некоторых правил.
"nocase|NC [=code]"
(не учитывать регистр)
Это делает Шаблон нечувствительным к регистру, т.е. нет различий между "A-Z" и "a-z",
когда Шаблон применяется к текущему URL
.
"qsappend|QSA [=code]"
(добавлять строку запроса)
Этот флаг указывает механизму преобразований на добавление, а не замену,
строки запроса из URL
к существующей, в строке подстановки. Используйте
это когда вы хотите добавлять дополнительные данные в строку запроса с
помощью директив преобразований.
"noescape|NE [=code]"
Этот флаг не даёт mod_rewrite
применять обычные правила экранирования URI
к результату
преобразования.
Обычно, специальные символы (такие как "%", "$", ";", и так далее) будут экранированы их шестнадцатиричными
подстановками ("%25", "%24", и "%3B", соответственно); этот флаг не дает это делать.
(не экранировать URI при выводе)
Если в подкаталогах в .htaccess нет ни одной директивы модуля mod_rewrite , то все правила преобразования наследуются из родительского каталога.
При наличии в файле .htaccess каких-либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию "off"). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву "RewriteEngine on " в .htaccess для конкретного каталога.
При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу - необходимо выставить в начале следующее: "RewriteEngine on " и "RewriteOptions inherit " - последняя директива сообщает серверу о продолжении.
Примеры использования mod_rewrite можно посмотреть
Если у Вас установлена операционная система семейства Windows , Вы можете подключится к серверу по SSH (инструкцию по подключению можно найти ) и воспользоваться утилитой htpasswd .
Запустив htpasswd
без параметров мы увидим:
|
beget@ginger
~ #
htpasswd Usage: htpasswd [-cmdps] passwordfile username htpasswd -b passwordfile username password -c Create a new file. beget@ginger ~ # |
Здесь не будут рассматриваться все параметры этой команды, но вы можете сами прочитать подробности, запустив htpasswd в unix shell , или ознакомившись с соответствующей страницей документации по Apache.
Итак, изначально у нас еще нет файла с паролями и нам нужно его создать:
А теперь мы хотим добавить еще одного пользователя. Так как файл с паролями у нас уже есть,
мы просто не будем использовать ключ "-c" :
Указывая valid-user , Вы разрешаете доступ всем пользователям, перечисленным в файле паролей.
Приведем пример для доступа определенных пользователей из файла с паролями .htpasswd
|
|
Следует помнить, что при таком ограничении доступа пароли передаются по каналам связи в открытом виде и при определенных обстоятельствах могут быть перехвачены злоумышленниками. Поэтому в целях безопасности рекомендуется организовывать доступ к закрытым областям веб-сайта через защищенное SSL-соединение .
Htaccess (с точкой в начале имени) – это файл, который дает возможность конфигурировать работу сервера в отдельных директориях (папках), не предоставляя доступа к главному конфигурационному файлу. Например, устанавливать права доступа к файлам в директории, менять названия индексных файлов, самостоятельно обрабатывать ошибки Apache, перенаправляя посетителей на специальные страницы ошибок.
Как известно, конфигурационные директивы сервера Apache находятся в файлe httpd.conf. Но далеко не всегда у Вас будут права доступа к этому файлу. Например, если Вы используете для хостинга виртуальный сервер, когда один сервер Apache обслуживает множество сайтов, то, естественно, Вам никто не позволит менять его конфигурацию. Но, тем не менее, вы можете конфигурировать работу сервера в своих директориях. И делать вы это можете с помощью файлов.htaccess.
Файл.htaccess может быть размещен в любом каталоге. Директивы этого файла действует на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов.htaccess).
Изменения, вносимые в файлы.htaccess, вступают в силу немедленно и не требуют перезагрузки сервера, в отличие от изменений, вносимых в главный конфигурационный файл httpd.conf.
Настройки httpd.conf, разрешающие применение файлов.htaccess
Для того, что бы эти файлы.htaccess можно было использовать - необходимы соответствующие настройки главного конфигурационного файла. В файле httpd.conf должны быть прописаны директивы, которые разрешат файлу.htaccess переопределять конфигурацию web-сервера в каталоге. Эта директива называется AllowOverride. Она может быть установлена как для всего сервера (глобально), так и для отдельного каталога.
Директива AllowOverride может включать в себя одну из следующих директив или их комбинацию: All, None, AuthConfig, FileInfo, Indexes, Limit, Options .
Для того чтобы дать директивам файлов.htaccess максимальные права следует прописать в httpd.conf:
AllowOverride All
Примечание
При желании название конфигурационного файла можно изменить, и например, назвать его не.htaccess, a access.conf. За название этого файла отвечает директива AccessFileName в файле httpd.conf. Но все же рекомендуется этого не делать.
Синтаксис.htaccess
Перед тем, как будут рассмотрены примеры, остановимся на синтаксисе директив в файлах.htaccess.
- Пути к файлам и директориям должны указываться от корня сервера, например, /pub/home/server1/html/
Если вы не знаете путь от корня сервера, то Вы можете его узнать, спросив у администратора сервера, либо можете посмотреть сами, запустив на сайте функцию PHP - phpinfo(). Она выведет на экран конфигурацию PHP в виде фиолетовых таблиц. В них Вам необходимо найти переменную doc_root и посмотреть ее значение - это будет путь от корня сервера до Вашей основной директории.
- В именах доменов обязательно должны быть указаны протоколы, например:
Примеры использования.htaccess
Глобальное перенаправление (редирект) на другой адрес:
Redirect / http://www.newsite.ru
Перенаправление (редирект) только при запросе определенных страниц:
Redirect /company http://www.newsite.com/newcompany
redirect /forum http://www.newsite.com/newforum
При запросе страниц из каталогов company и forum будет произведено перенаправление на новые адреса.
Перенаправление (редирект) только посетителей с определенным IP-адресом:
SetEnvIf REMOTE_ADDR 192.145.121.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /only_for_you.html
Если посетитель имеет IP-адрес 192.145.121.1, то ему будет открыта страница only_for_you.html.
Изменение названия индексной страницы:
DirectoryIndex index.html index.php index.shtml
Можно указать несколько индексных страниц. При запросе каталога они будут искаться в том порядке, в котором перечислены в директиве DirectoryIndex. Если не будет найден файл index.html, то будет произведен поиск файла index.php и т.д.
Выполнять код PHP в файлах HTML
RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html .phtml
Добавив эти строки в.htaccess вы дадите директиву серверу выполнять инструкции PHP не только в файлах с расширением *.php и *.phtml, но и в файлах с расширением *.htm и *.html.
Обработка ошибок Apache
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
При возникновении этих ошибок посетитель будет перенаправлен на специально созданные страницы.
- 401 ошибка - Требуется авторизация (Authorization Required).
- 403 ошибка - пользователь не прошел аутентификацию, доступ запрещен (Forbided).
- 404 ошибка - Документ не найден (Not Found).
- 500 ошибка - Внутренняя ошибка сервера (Internal Server Error).
Запрет на отображение содержимого каталога при отсутствии индексного файла
Options –Indexes
Определение кодировки, в которой сервер "отдает" файлы
AddDefaultCharset windows-1251
Определение кодировки на загружаемые файлы
CharsetSourceEnc windows-1251
Запрет доступа ко всем файлам
Deny from all
Запрещен доступ ко всем файлам и каталогам в текущей директории.
Разрешить доступ только с определенного IP-адреса
Order deny,allow
deny from all
allow from 195.135.232.70
Строка order deny,allow определяет, в каком порядке следует выполнять директивы. Сначала выполняется директива запрета доступа, а затем разрешается доступ только для IP-адреса 195.135.232.70. Если в первой строке поменять порядок следования директив на order allow,deny, то доступ для данного IP-адреса не будет открыть, так как директива deny, выполняемая последней перекроет действия директивы allow.
