Большая энциклопедия возможностей .htaccess


Не секрет, что каждый веб-мастер стремится как можно лучше настроить свой проект для достижения оптимального пользовательского опыта. Каждый день и каждую секунду творец думает о своем детище и его улучшении, что неудивительно. 

Многие из настроек доступны только на серверном уровне, и часто для веб-мастера это становится головной болью и долгим поиском решения проблемы.

Ну что ж, сегодня мы хотим познакомить вас с, так сказать, серверным ибупрофеном – файлом .htaccess, настройка которого позволяет изменять работу сервера Apache в отдельно взятых директориях: например, разграничивать доступ к директориям, а также решать вопросы с безопасностью сайта и в целом управлять его настройками.

Мы подготовили подробный материал, в котором детально разберем ключевые возможности этого конфигурационного файла и тонкие нюансы его настройки под конкретные нужды. Наша статья будет полезна, если у вас есть виртуальный сервер и вы хотите управлять работой веб-сервера Apache для развития своего проекта.

Сразу предупредим: статья получилась объемной и очень полезной, поэтому запаситесь чаем и печеньками :)

Итак, что такое .htaccess и как его использовать себе на благо – читайте в этой статье.

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

В этом и многих других случаях вас может выручить файл .htaccess.

 

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

Перед тем как переходить к возможностям .htaccess, для начала разберем, что он вообще из себя представляет.

Что такое .htaccess и почему он так называется

.htaccess – это файл дополнительной конфигурации веб-сервера Apache, который позволяет задавать множество дополнительных параметров и разрешений для работы сервера, не влияя на работу всего сервиса целиком.

С названием .htaccess (сокр. от англ. hypertext access – гипертекстовый доступ) всё просто – оно указывает, что файл служебный и не относится непосредственно к файлам сайта, а применяется для настроек веб-сервера, являясь частью конфигурации Apache. Размещаться этот конфигурационный файл может в любом каталоге сайта, обычно основной файл .htaccess размещается в каталоге public_html.

Теперь, когда с названием и определением .htaccess разобрались, можно смело переходить к его возможностям :)

Ключевые возможности .htaccess

 В .htaccess задаются серверные настройки Apache – в нем можно:

  • исправить кодировку – ее можно менять, если тексты на сайте превратились в набор непонятных символов;
  • настроить редирект или, проще говоря, переадресацию с одного адреса на другой;
  • настраивать страницы ошибок, которые пользователи увидят вместо непонятного технического текста;
  • создать нужный URL для улучшения SEO-показателей сайта;
  • закрыть доступ к сайту для поисковых ботов и ограничить его для определенных нежелательных IP-адресов.

 

И это далеко не полный перечень возможностей :)

 

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

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

Обратите внимание, в части добавления директив вся власть – исключительно в ваших руках. То есть директивы можно и нужно добавлять в .htaccess без дополнительных условий и редактирования: вы просто добавляете их в файл и – и всё будет работать. Практически магия :)

 

➯ Директивы простого перенаправления (редирект)

 

Эти директивы используются чаще всего. Допустим, вам нужно перенаправить пользователей на актуальную версию вашего сайта или вы планируете отбалансировать нагрузку из-за слишком большого количества посетителей – в этих и других случаях можно настроить работу сайта так, чтобы при его запросе пользователи переадресовывались на другой URL. 

Для этого следует в корневую директорию сайта добавить файл .htaccess со следующим содержимым:

 

Redirect / http://www.example.com

 

Где http://www.example.com – URL, на который вы перенаправляете запросы.

 

Или другой пример. Если необходимо переадресовывать на другие сайты определенные страницы вашего сайта, то содержимое .htaccess должно быть таким:

 

Redirect /example http://www.example.org

Redirect /example/download.html http://www.example.org/dist/download_info.html

Redirect 301 /example1 http://www.example.org

 

В данном случае при обращении пользователей к http://mysite.ru/example будет открываться http://www.example.org, а при обращении к http://mysite.ru/example/download.html – http://www.example.org/dist/download_info.html. 

 

Во втором примере сервер будет передавать код 301, указывающий, что документ перемещен постоянно.

Синтаксис команды Redirect выглядит так:

 

Redirect [status] URI_LOCAL URL_REDIRECT

 

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

 

    * permanent (301 – документ перемещен постоянно)

    * temp (302 – документ перемещен временно)

    * seeother (303 – смотрите другой)

    * gone (410 – убран)

 

В данном синтаксисе URI_LOCAL обозначает локальную часть URL запрашиваемого документа, а URL_REDIRECT – URL, куда, собственно, должен быть выполнен редирект.

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

 

➯ ДИРЕКТИВЫ СЛОЖНОГО ПЕРЕНАПРАВЛЕНИЯ (MOD_REWRITE)

 

Бывают ситуации, когда URL нужно преобразовать – например, для улучшения читаемости (длинные и сложные URL можно заменять на более понятные и запоминающиеся) и создания динамического контента на основе URL-адресов (к примеру, параметры URL можно преобразовать в запросы к базе данных или в дополнительные параметры для скриптов на сервере). 

 

В этих и многих других случаях на выручку придет модуль mod_rewrite, с помощью которого возможны почти все типы преобразований URL. Модуль поддерживает неограниченное количество правил и связанных с каждым правилом условий, реализуя гибкий и мощный механизм управления URL, а сами преобразования могут использовать разные источники данных – например, переменные сервера, переменные окружения, заголовки HTTP, время и даже запросы к внешним базам данных в разных форматах для получения URL нужного вам вида.

 

При использовании mod_rewrite нужна одна или несколько директив RewriteCond (она определяет условие, при котором происходит преобразование), она располагается перед директивой RewriteRule.

 

Директива RewriteEngine включает/выключает работу механизма преобразования. Если она установлена в положение off, модуль mod_rewrite не работает. 

Синтаксис RewriteEngine выглядит так:

 

RewriteEngine on | off

 

По умолчанию: RewriteEngine off

 

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

 

RewriteEngine on

 

*Данный набор директив приведен в качестве примера для наглядности комбинирования условий.

 

Подробный разбор синтаксиса каждого из элементов этих команд можно найти в нашей статье.

 

Mod_rewrite – практически волшебный модуль, примеров его использования довольно много, с некоторыми из них можно ознакомиться здесь, а мы пока перейдем к следующей возможности настройки сайта в рамках использования .htaccess.

 

➯ Индексные страницы

 

Когда любой пользователь заходит на сайт, например, http://gentoo.org, открывается индексный файл index.*, а при его отсутствии отображается либо содержимое каталога, либо отдается ошибка 403 FORBIDDEN (если отключена опция “просмотр директорий”).

 

За листинг файлов (то есть вывод содержимого директории при отсутствии индексного файла) отвечает директива Indexes и порой нужно сделать так, чтобы в случае отсутствия в каталоге файла, который показывается по умолчанию, листинг (проще говоря, список файлов в каталоге) не выдавался. 

В этом случае в .htaccess следует добавить такую строчку:

 

Options -Indexes

 

Соответственно, чтобы листинг выдавался, строчка должна быть следующей:

 

Options Indexes

 

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

 

IndexIgnore *.php* *.pl

 

В данном примере мы запретили отображение в листинге файлов с расширением .php и .pl, но запретить, разумеется, можно и отображение файлов с другим расширением.

Бывает и так, что сайт построен на скриптах и тогда в качестве индексных часто могут использоваться файлы с другими расширениями. Указать их можно с помощью директивы DirectoryIndex:

 

DirectoryIndex index.html index.shtml index.pl index.cgi index.php

 

Если же вы хотите, чтобы при обращении к каталогу открывался не index.html, а, например, файл htaccess.php или /cgi-bin/index.pl, то строчка должна быть следующей:

 

DirectoryIndex htaccess.php /cgi-bin/index.pl

 

➯ Обработка ошибок

 

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

Грамотным решением будет называть ошибки не сбоями в работе сервера, а стандартными кодами возврата, оговоренными в стандарте HTTP_RFC2616

 

Такие ошибки всегда имеют свой код – трехзначное число, по которому можно определить, что именно произошло с запросом. Коды ошибок, начинающиеся с цифры “4”, говорят о том, что проблема на стороне пользователя, а те, которые начинаются с цифры “5”, свидетельствуют о проблемах на стороне сервера. При возникновении таких ошибок на сайте обычно появляется шаблонное и непонятное рядовому пользователю серверное сообщение. Используя .htaccess, можно настроить страницу, которую пользователи увидят в случае ошибки вместо непонятного технического текста.

 

Приведем простой пример переопределения страниц ошибок:

 

# содержание файла .htaccess:

 

ErrorDocument 404 http://bg10.ru/error/404.htm

ErrorDocument 403 http://bg10.ru/error/403.htm

ErrorDocument 400 http://bg10.ru/error/400.htm

ErrorDocument 500 http://bg10.ru/error/500.htm

 

# в случае "403 FORBIDDEN" вместо страницы можно указать текстовое сообщение (оно обязательно должно начинаться с кавычки, кавычка в сообщении не выводится):

 

ErrorDocument 403 "Sorry can't allow you access today, 403 Status Codes Apache"

 

В таком случае при наличии ошибки вместо сложного технического текста пользователи увидят указанную вами страницу.

Более подробно об обработке ошибок можно узнать здесь, а мы перейдем к следующему пункту.

 

➯ Кодировка

 

Бывает так, что браузер пользователя не может правильно определить тип кодировки выдаваемого документа. Для решения этой проблемы используемая кодировка указывается в настройках веб-сервера Apache и заголовке передаваемого документа, причем для корректного распознавания эти кодировки должны совпадать. К слову, на наших серверах по умолчанию используется двухбайтовая кодировка UTF-8 – поскольку она универсальна, обеспечивает поддержку всех основных языков и широко используется в интернет-протоколах (HTTP, HTML, XML, JSON, FTP и др.).

 

Рассмотрим указание кодировки по умолчанию через .htaccess. Директива AddDefaultCharset задает кодировку для всех отдаваемых страниц на веб-сервере Apache.

 

Если вам нужно указать кодировку на все файлы – WINDOWS-1251, в которой по умолчанию получает документы браузер, в .htaccess следует добавить такую строчку:

 

AddDefaultCharset WINDOWS-1251

 

При загрузке файла на сервер возможна перекодировка. Чтобы указать, что все получаемые файлы будут иметь кодировку windows-1251, нужно написать:

 

CharsetSourceEnc WINDOWS-1251

 

Если же необходимо отменить перекодировку сервером файлов, запись будет следующей:

 

CharsetDisable on

 

➯ Ограничение доступа

 

Когда проект доступен пользователям с разными IP-адресами, иногда может возникнуть необходимость ограничения доступа для тех или иных IP. Возможности .htaccess позволяют сделать и это.

Для запрета или разрешения доступа ко всем файлам и папкам в текущей и во всех вложенных директориях используется директива Order, синтаксис ее очень прост:

 

Order [Deny,Allow] | [Allow,Deny]

 

# По умолчанию используется значение Deny,Allow

 

В зависимости от того, в каком порядке указаны директивы, меняется логика работы сервера: в случае если указано Deny,Allow, запрещается доступ со всех IP, кроме оговоренных, в случае Allow,Deny – разрешается доступ со всех IP, кроме оговоренных. Далее располагаются секции описания для доступа и запрета, а ключевое слово all означает со всех IP.

 

К примеру, вы хотите запретить доступ с IP 81.222.144.12 и 81.222.144.20 и разрешить всем остальным – в этом случае в .htaccess следует добавить следующий код:

 

Order Allow,Deny

Allow from all

Deny from 81.222.144.12 81.222.144.20

 

В обратном случае, если необходимо запретить доступ со всех IP, кроме 81.222.144.12 и 81.222.144.20, в .htaccess нужно добавить такой код:

 

Order Deny,Allow

Deny from all

Allow from 81.222.144.12 81.222.144.20

 

Также можно запретить или разрешить доступ к определенной группе файлов – например, к файлам с расширением ".key":

 

<Files "\.(key)$">

  Order Deny,Allow

  Deny from all

  Allow from 81.222.144.12

</Files>

 

Вполне логично, что при помощи .htaccess, наряду с настройкой доступа в целом, также можно устанавливать пароли на доступ к определенным папкам, файлам и группам файлов. 

 

➯ Паролирование директорий

 

Приведем рабочий пример, а затем поясним, что к чему с его содержимым:

 

AuthName "Protected area, need authorization"

AuthType Basic

AuthUserFile /home/t/test/.authfile

require valid-user

 

Файл .htaccess с этим содержимым необходимо разместить в директории, на которую вы хотите поставить пароль.

 

Теперь разберемся с директивами:

■ AuthName – она выводит сообщение при запросе пароля. Всё сообщение следует писать в одну строчку, синтаксис директивы выглядит так:

Синтаксис: AuthName “SEE TEXT”

 

■ AuthType – эта директива указывает тип аутентификации. Подробнее про типы аутентификации можно прочитать в официальной документации.

 

Синтаксис: AuthType None | Basic | Digest | Form

 

■ AuthUserFile – данная директива указывает имя файла с паролями для аутентификации пользователей (пароли в этом файле будут шифрованными). Путь к файлу с паролями задается относительно корня веб-сервера. Мы рекомендуем хранить файл с паролями в папке, доступ к которой закрыт для пользователей – желательно поместить этот файл вне иерархии вашего веб-сайта, например, рядом с каталогом public_html. Размещать его выше каталога сайта нецелесообразно – это не увеличит безопасность, но потребует дополнительной настройки прав доступа в связи с изоляцией сайтов.

 

Затем вы можете подключиться к серверу по SSH и воспользоваться утилитой htpasswd.

 

Запустив htpasswd без параметров, вы увидите:

 

beget@ginger ~ # htpasswd

   Usage:

   htpasswd [-cmdps] passwordfile username

   htpasswd -b[cmdps] passwordfile username password

   -c Create a new file.

 beget@ginger ~ #

 

Со всеми параметрами команды htpasswd вы можете ознакомиться здесь.

 

Итак, для установки паролей на доступ в первую очередь необходимо создать сам файл с паролями:

 

beget@ginger ~ # htpasswd -c .authfile test1

   New password:

   Re-type new password

   Adding password for user test1

 beget@ginger ~ #

 

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

 

beget@ginger ~ $ cat .authfile

   test1:zgco1KREjBY8M

beget@ginger ~ $

 

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

 

beget@ginger ~ # htpasswd .authfile test2

   New password:

   Re-type new password:

   Adding password for user test2

 

beget@ginger ~ $ cat .authfile

   test1:zgco1KREjBY8M

   test2:eN3uA6t0kzV1c

beget@ginger ~ $

 

Для назначения пользователей, которые могут получить доступ, следует воспользоваться директивой Require:

 

Require USER_NAME | valid-user

 

Указывая valid-user, вы разрешаете доступ всем пользователям, перечисленным в файле паролей.

 

Приведем пример для доступа определенных пользователей из файла с паролями .htpasswd:

 

AuthName "Protected area, need authorization"

AuthType Basic

AuthUserFile /home/t/test/.authfile

require Alexey Kondr Fenix

 

Так же, как и с запретом доступа по IP, здесь можно использовать расширение <Files> . 

 

А теперь мы приведем два примера – установку пароля на один определенный файл и на группу файлов.

 

<Files "passwd.html">

  AuthName "Protected area, need authorization"

  AuthType Basic

  AuthUserFile /home/t/test/.authfile

  require valid-user

</Files>

 

<Files "\.(key)$">

  AuthName "Protected area, need authorization"

  AuthType Basic

  AuthUserFile /home/t/test/.authfile

  require valid-user

</Files>

 

Отметим, что при таком ограничении доступа пароли передаются по каналам связи в открытом виде и при определенных обстоятельствах могут быть перехвачены злоумышленниками, поэтому в целях безопасности мы рекомендуем организовывать доступ к закрытым областям сайта через защищенное SSL-соединение.

 

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

 

➯ Запрет на выполнение вредоносных скриптов

 

Грамотная настройка .htaccess позволяет защитить сайт от вредоносных программ.

Для этого можно использовать такие директивы:

 

Эти директивы помогут предотвратить выполнение вредоносных скриптов и в результате злоумышленник попадет на страницу с ошибкой 403 («Доступ запрещен»).

 

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

 

Чек-лист: как не навредить сайту при работе с .htaccess

✔ Никакой кириллицы – URL на кириллице следует переводить в Punycode (кириллические домены используются так, как они указаны в whois).

✔ Позаботьтесь о возможности восстановить всё – бэкапы позволят обеспечить данным сохранность, поэтому перед изменением .htaccess лучше сделать его копию.

✔ Избавляйтесь от мусора – при тестировании директив очищайте данные и кэш браузера.

 

Заключение

 

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

 

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

 

Надеемся, наш материал был для вас полезен и настройка .htaccess станет почти такой же простой, как ввод капчи на сайтах :)

 

Если у вас появились вопросы о конфигурационном файле .htaccess или вы просто хотите поделиться опытом его использования, ждем вас в комментариях. 


Предложить идею урока:

Ошибка в тексте

Послать сообщение об ошибке администратору?
Ваш браузер останется на той же странице.

Ваше сообщение отправлено. Спасибо!

Окно закроется автоматически через 3 секунды

Наверх