Управление веб-сервером Apache с помощью механизма .htaccess

 В подавляющем большинстве случаев для хостинга используется веб-сервер apache. Это программа, которая осуществляет прием http-запросов, их обработку и выдачу посетителю сервера конечного результата - html-документов, картинок, файлов и так далее. Домашняя страница проекта apache - http://www.apache.org/.

apache может настраиваться через файл конфигурации, в который администратор помещает инструкции, непосредственно влияющие на функционирование веб-сервера. Обычно в условиях хостинга конечные пользователи не имеют доступа к файлу конфигурации (httpd.conf), так как не всегда это нужно и не все хостинговые компании могут такую возможность предоставить.

Учитывая эти реалии, а также стремясь добавить в apache возможности более гибкой настройки, авторы этого веб-сервера реализовали допустимость децентрализованного управления конфигурацией с помощью использования специальных файлов, которые помещаются на диске прямо в веб-пространстве виртуального сервера. Эти файлы обычно называются .htaccess (обратите внимание на первый символ в названии файла - точку), но администратор сервера может менять имя таких файлов по своему желанию с помощью директивы accessfilename в главном файле конфигурации.

Действие команд из файла .htaccess распространяется и на подкаталоги того каталога, в котором этот файл размещен. Файл .htaccess перечитывается при каждом обращении к веб-серверу, так что изменения, внесенные в этот файл, вступают в силу немедленно.

Синтаксис файлов .htaccess в общем случае аналогичен синтаксису главного файла конфигурации. Однако, администратор может ограничивать для пользователей доступ к тем или иным директивам. То есть, несмотря на то, что команда, в принципе, может исполняться из .htaccess, администратор может запретить доступ к конкретной директиве. Учитывайте это при работе.

Список всех директив apache можно посмотреть тут. В описании каждой директивы есть поле context. Оно указывает на то, откуда может исполняться данная директива. Если в описании нужной команды в поле context отсутствует упоминание о возможности использования из .htaccess, значит, Вы не сможете применять эту директиву.

Теперь перейдем к практике. Сначала нужно создать в каком-то каталоге веб-сервера файл .htaccess, куда в дальнейшем и будут помещаться директивы. Создать файл можно как с помощью ftp-клиента, так и в unix shell (если он у Вас есть).

Далее мы рассмотрим наиболее полезные и часто используемые пользователями хостинга директивы, которые могут быть вызваны из .htaccess.

directoryindex - переопределение файла по умолчанию

Обычно принято файл, который открывается веб-сервером при обращении к каталогу, называть именем index.htm или index.html. Иногда возникает необходимость дать такому файлу другое имя. То есть, сделать так, чтобы при обращении к каталогу открывался не index.html, а, например, файл 123.php3 или /cgi-bin/index.pl. Для этого добавим в файл .htaccess такую строку :

directoryindex 123.php3 /cgi-bin/index.pl

При обращении к каталогу apache попытается найти один из указанных файлов и показать посетителю его содержимое, а если сделать этого не получится, сервер выдаст пользователю список файлов в каталоге.

Иногда нужно сделать так, чтобы в случае отсутствия в каталоге файла, который показывается по умолчанию, листинг, то есть список файлов в каталоге, не выдавался. В этом случае можно попробовать добавить в .htaccess такую строчку :

options -indexes

В этом случае вместо списка файлов в каталоге посетитель получит http ошибку 403 - access forbidden. Это ошибку можно обработать и показать пользователю какую-нибудь красивую страничку вместо неинформативного сообщения от веб-сервера.

errordocument - обработка ошибок

Иногда в работе сервера возникают ошибки. Здесь речь идет не о сбоях в работе программного обеспечения, а об ошибках в терминах интернет-стандарта на протокол http - rfc2616. Вообще, в rfc ошибки называются "status codes", но мы их будем называть именно ошибками - так привычнее.

Теория такова: клиент присылает на сервер http-запрос, сервер выполняет какие-то операции и возвращает клиенту код возврата и некоторые данные, текстовые или двоичные - вот что происходит каждый раз, когда Вы с помощью своего браузера обращаетесь к любому веб-серверу.

Код возврата - это трехзначное число, на основании которого можно судить о том, насколько успешно был обработан запрос. Так, например, коды возврата, начинающиеся с цифр 1, 2 или 3, являются положительными. А вот если веб-сервер вернул Вам код, начинающийся на 4 или 5, то явно произошла какая-то ошибка. Код 4xx выдается в случае возникновения ошибки в процессе обработки запроса, а 5xx означает критическую ошибку или то, что запрос не может быть выполнен вообще.

Вот список ошибок 4xx и 5xx :

400 - bad request
401 - unauthorized
402 - payment required
403 - forbidden
404 - not found
405 - method not allowed
406 - not acceptable
407 - proxy authentication required
408 - request time-out
409 - conflict
410 - gone
411 - length required
412 - precondition failed
413 - request entity too large
414 - request-uri too large
415 - unsupported media type
500 - internal server error
501 - not implemented
502 - bad gateway
503 - service unavailable
504 - gateway time-out
505 - http version not supported

Детальное описание каждого кода можно найти в rfc2616.

При возникновении ошибки 4xx или 5xx посетитель Вашего сайта увидит в браузере сообщение от сервера, которое вряд ли можно назвать предельно понятным рядовому пользователю. apache предоставляет возможность выдать вместо аскетичного технического текста, не изобилующего деталями, свою страницу, где Вы можете человеческим языком объяснить пользователю, что произошло и что делать.

Рассмотрим примеры. Допустим, пользователь обратился к документу, которого не существует на сервере. Такое может произойти по разным причинам: где-то осталась ссылка на уже удаленный Вами документ, кто-то дал пользователю неправильную ссылку или пользователь допустил ошибку, когда набирал адрес страницы в браузере. В этом случае сервер выдаст ошибку 404 (not found) и текст вида "the requested url такой-то was not found on this server". Можно выдать вместо этой строчки документ в дизайне Вашего сервера, в котором написать что-то типа "Произошла ошибка - запрошенный документ не найден. Попробуйте уточнить адрес, воспользоваться поисковой системой или начать просмотр сайта с первой страницы". Такое сообщение пользователь поймет гораздо лучше. Более того, пожалуй, выдача дружественных, понятных любому посетителю сообщений является хорошим тоном.

Итак, создаем документ, который будем показывать пользователю в случае возникновения ошибки 404. Назовем файл missing.html, напишем туда все те добрые слова, которыми мы хотим успокоить пользователя, и поместим этот файл в веб-пространство. Допустим, это файл будет доступен как http://Ваш_Сервер/missing.html. В файл .htaccess помещаем такую строчку :

errordocument 404 /missing.html

Все! Теперь при возникновении ошибки 404 пользователь увидит именно Ваш файл. Еще можно скриптом или с помощью ssi вставить в выдаваемый документ какую-нибудь служебную информацию, которую пользователь должен будет привести, если решит обратиться за комментариями к Вам по e-mail.

Таким образом можно обработать практически все негативные коды возврата. Конечно, можно обработать и позитивные коды, но смысл этого не до конца ясен, равно как непонятно в какой ситуации это может пригодиться :).

Стоит упомянуть об одной особенности браузера ms internet explorer версии 5. Если файл missing.html (так мы его назвали в нашем случае) будет иметь размер менее 1Кб, ie5 покажет пользователю не missing.html, а свое собственное сообщение об ошибке 404.

Более подробно об обработке ошибок можно прочитать в документации по apache на странице "custom error responses".

auth* - защита паролем

Еще можно использовать .htaccess для установки пароля на доступ к определенным страницам или разделам Вашего сайта. Делается это путем создания в нужном подкаталоге файла .htaccess, в который пишем следующее:

<files admin.php>
authname "access restricted"
authtype basic
authuserfile /path/tofile/passwords
require valid-user
</files>

Данный код запрещает доступ к файлу admin.php, если же удалить первую и последнюю строчку кода, то доступ будет запрещен к каталогу где лежит .htaccess и ко всем подкаталогам пока не будет введен правильный пароль.

Кроме того, нужно создать файл с паролями, путь к которому указывается в качестве параметра к директиве authuserfile. Пароли в этом файле должны быть шифрованными, чего можно достигнуть с помощью программы htpasswd, входящей в поставку apache. Если Вы набрали в unix shell команду htpasswd и система сообщила что такого файла нет, выясните у своего хостинг-провайдера где же находится htpasswd.

Пример создания файла passwords: :

> htpasswd -c passwords test1
new password:
re-type new password:
adding password for user test1
>

После выполнения данной операции htpasswd создаст файл passwords, в котором окажется пользователь test1 и его пароль в зашифрованном виде:

> cat passwords
test1:zgco1krejby8m
>

А теперь мы хотим добавить еще одного пользователя. Так как файл с паролями у нас уже есть, мы просто не будем использовать ключ '-c' :

> htpasswd passwords test2
new password:
re-type new password:
adding password for user test2

> cat passwords
test1:zgco1krejby8m
test2:en3ua6t0kzv1c
>

Файл с паролями может иметь любое имя. Однако, вам следует обратить внимание на то, что такой файл не должен быть доступен пользователям через http. Это требование продиктовано соображениями безопасности. Дело в том что, добравшись до файла с паролями, его можно расшифровать и получить доступ к вашему сайту. Скрыть файл паролей можно несколькими путями.

1. Надежнее всего разместить его в корне вашего сервера, то есть здесь: /pub/home/ваш_логин/. В этом случае файл паролей находится выше по дереву каталогов, чем корневая папка вашего веб-сервера (/pub/home/ваш_логин/htdocs), и добраться до него средствами http невозможно.
2. Вы можете разместить файл с паролями в любом месте вашего сервера, но первые три символа в его названии должны быть .ht (точка ht). Дело в том, что по умолчанию веб-сервер apache сконфигурирован так, что скрывает файлы начинающиеся на эти три символа от доступа через http протокол.
3. Вы можете разместить файл с паролями в любом месте вашего сервера и назвать его как угодно. Но тогда вам надо ограничить доступ к нему через возможности конфигурационного файла .htaccess, который надо разместить в той же папке, что и файл паролей. Для ограничения доступа к вашему файлу паролей user.pas добавьте в файл .htaccess такие строки:

<files user.pas>
order allow,deny
deny from all
</files>

В качестве параметра к директиве require мы указали valid-user. Это означает, что любой пользователь, который есть в используемом файле с паролями, может иметь доступ к защищенному ресурсу. Однако, согласитесь, удобно иметь все пароли в одном файле, а права на конкретные ресурсы давать только определенным пользователям. Это тоже реализуемо. Например, мы хотим дать доступ только пользователю test2. Делаем так :

require user test2

Еще можно объединить пользователей в группы и давать доступ не конкретным логинам, а группам. Это можно сделать с помощью директивы authgroupfile :

authgroupfile /path/to/file/with/groups

В файле /path/to/file/with/groups создаем группы примерно так :

group1: test1 test5
group2: test2 test4
group3: test1 test3

Соответственно, директиву require будем использовать так :

require group group3

Механизмы ограничения доступа, которые реализованы в apache, позволяют очень гибко управлять правами для пользователей и групп, что является очень важной возможностью. Если углубиться в изучение предмета, Вы сможете узнать и то, что логины и пароли, используемые для авторизации, можно хранить не только в файлах, но и в простейших базах данных формата berkeleydb - почитайте документацию по директиве authdbgroupfile. Еще для хранения данных авторизации можно использовать практически любую СУБД (mysql или postgresql, например), но это уже выходит за рамки данной статьи.

order, allow, deny - запрет доступа для определенныхпосетителей

Признайтесь, ведь наверняка хоть один раз у Вас было желание запретить кому-то заходить на Ваш веб-сервер? И это тоже можно сделать с помощью .htaccess :

<limit get>
order allow,deny
deny from 195.1.1.1
allow from all
</limit>

Мы запретили пользователю с ip адресом 195.1.1.1 смотреть Ваш сайт. Если вместо 195.1.1.1 написать 195.1.1, то доступ будет запрещен для всей сети класса c 195.1.1.0/24. Подробнее читайте в документации по команде deny.

Как сделать перенаправление (редирект) посетителя?
Редирект на другой url:
Что бы сделать перенаправления посетителя на сайт http://site.ru в .htaccess пишем:
redirect / http://www.site.ru

Показ разных страниц, в зависимости от ip адреса посетителя:
setenvif remote_addr <нужный ip адрес> redir="redir"
rewritecond %{redir} redir
rewriterule ^/$ /another_page.html

Например, перенаправление посетителей с ip адресом 192.12.131.1 на страницу about_my_sity.html:
setenvif remote_addr 192.12.131.1 redir="redir"
rewritecond %{redir} redir
rewriterule ^/$ /about_my_sity.html