Настройка файла .htaccess

How directives are applied

The configuration directives found in a file
are applied to the directory in which the file
is found, and to all subdirectories thereof. However, it is important
to also remember that there may have been files
in directories higher up. Directives are applied in the order that they
are found. Therefore, a file in a particular
directory may override directives found in files
found higher up in the directory tree. And those, in turn, may have
overridden directives found yet higher up, or in the main server
configuration file itself.

Example:

In the directory we have a
file containing the following:

(Note: you must have «» in effect
to permit the use of the «» directive in
files.)

In the directory we have
a file containing:

Because of this second file, in the directory
, CGI execution is not
permitted, as only is in effect, which
completely overrides any earlier setting that may have been in
place.

Merging of .htaccess with the main
configuration files

As discussed in the documentation on Configuration Sections,
files can override the sections for
the corresponding directory, but will be overridden by other types
of configuration sections from the main configuration files. This
fact can be used to enforce certain configurations, even in the
presence of a liberal setting. For example, to
prevent script execution while allowing anything else to be set in
you can use:

Как переопределить кодировку HTML-документов

Мы хотим «объяснить» веб-серверу что все html-документы, которые размещены на сервере, нужно «отдавать» клиенту в кодировке koi8-r, а не в windows-1251, как это сервер делает по умолчанию. Для этого поместим в строку:

Получив такой , веб-сервер Apache станет выдавать клиентскому браузеру заголовок, в котором будет указано, что документ имеет кодировку koi8-r.

Если на вашем ресурсе существуют html-документы в разных кодировках, (ISO-8859-1, Windows-1250, Windows-1252, UTF-8), то вам, возможно, будет необходимо отключить принудительну выдачу заголовка с кодировкой windows-1251. Для этого в .htaccess добавляется строка: AddDefaultCharset Off

При этом соответствующая кодировка должна быть прописана на каждой html-странице в виде тега <http-equiv=»Content-type» content=»text/html; charset=utf-8″ />

Это примеры простейшего использования возможностей конфигурирования Apache через файл .htaccess.

Как применяются директивы файла .htaccess

Конфигурационные директивы, найденные в файле .htaccess, применяются к директории, в которой найден файл .htaccess, и всем её поддиректориям

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

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

Пример:

В директории /www/htdocs/example1 у нас есть файл .htaccess содержащий следующее:

Options +ExecCGI

Примечание: у вас должна быть включена опция «AllowOverride Options» чтобы разрешить использовать директиву «Options» в .htaccess файлах. Либо значение AllowOverride должно быть установлено на All.

В директории /www/htdocs/example1/example2 у нас есть файл .htaccess содержащий:

Options Includes

Поскольку второй файл .htaccess в директории /www/htdocs/example1/example2, то выполнение CGI не разрешено, поскольку эффект будет иметь опция Options Includes, которая полностью перезаписывает значения настроек Options, имеющих место ранее.

Подключение файла .htaccess

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

$ sudo nano /etc/apache2/sites-available/default

Найдите в этом файле следующий раздел и измените значение параметра AllowOverride c None на All. В конечном итоге раздел должен выглядеть так:

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all

Сохраните и закройте этот файл, а затем перезапустите apache.

$ sudo service apache2 restart

Создание и редактирование .htaccess

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

2. Выберите пункт меню «Файл» — «Новый файл».

3. Выберите из списка расширений .htaccess.

4. Нажмите кнопку «Создать файл».

Возникновение ошибки «Имя уже используется» означает, что данный файл уже создан в текущей директории.

Для редактирования файла в файловом менеджере перейдите в директорию с данным файлом, выделите его кликом левой кнопки мыши и выберите пункт меню «Файл» — «Редактировать».

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

Вы также можете редактировать .htaccess во внешних редакторах, но обратите внимание, что текстовые редакторы Windows (например, «Блокнот») при сохранении любых документов с кодировкой UTF-8 добавляют в них метки порядков байтов юникода — BOM-сигнатуры. Файлы с такой сигнатурой некорректно обрабатываются веб-сервером, поэтому мы рекомендуем редактировать .htaccess напрямую в «Файловом менеджере» или через специальный редактор «Notepad++»

Как настроить заголовок last-modified

В ряде случаев требуется, чтобы web-сервер выдавал HTTP-заголовок Last-Modified. К примеру, при регистрации вашего ресурса на Яндексе, возникает ошибка «Неправильные даты». Для статических документов cервер будет выдавать значение last-modified всегда. Это действительно для html-файлов.

Для SSI cервер будет выдавать значение last-modified в том случае, если прописана директива «XBitHack full» (просто пропишите эту строку в .htaccess), и для файла, к которому происходит обращение, выставлен атрибут «исполняемый» для группы. В скриптах last-modified выдается иными средствами. Например, если учесть то, что php-скрипт генерирует код динамически, то самым логичным будет в качестве last-modified отдавать текущую дату и время./>

Реализуется это следующим образом:

Дополнительно можете изучить:

Функцию header;
Функции для работы с сервером Apache.

Сообщения об ошибках

Файл .htaccess позволяет вам создавать для своего сайта собственные страницы, сообщающие об ошибках. Вот некоторые из наиболее распространенных ошибок:

400 Ошибка в запросе
401 Требуется авторизация
403 Доступ запрещен
404 Файл не найден
500 Внутренняя ошибка сервера

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

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

ErrorDocument 404 /new404.html

В рассматриваемом примере сервер будет искать страницу 404 в корневой директории сайта. Если она находится в какой-либо поддиректории, нужно указать путь, например:

ErrorDocument 404 /error_pages/new404.html

Как включить .htaccess

Включение поддержки файла .htaccess сказывается на производительность сервера даже в том случае, если фактически этот файл не используется (объяснение ниже). Поэтому по умолчанию файл .htaccess отключён в Apache.

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

<Directory "${SRVROOT}/htdocs">
    Options Indexes FollowSymLinks

    AllowOverride None

    Require all granted
</Directory>

Как видно, AllowOverride установлен на None. Вместо None можно указать All или любые комбинации ключевых слов, например:

AllowOverride FileInfo AuthConfig Limit

Для включения всех возможностей .htaccess установите так:

<Directory "${SRVROOT}/htdocs">
    Options Indexes FollowSymLinks

    AllowOverride All

    Require all granted
</Directory>

Чтобы настройки вступили в силу, перезапустите веб-сервер.

Файл .htaccess находится не в папках Apache, а в папках сайтов, то есть к нему может быть сделан запрос и, при неправильной настройке, посторонние его могут скачать. Файл .htaccess содержать информацию интересную для атакующего (хакеров), поэтому нужно запретить посторонним доступ к этому файлу. Запрет доступа к файлам .htaccess и .htpasswd для посетителей сайтов делается следующим образом:

<Files ".ht*">
    Require all denied
</Files>

По умолчанию эта настройка уже имеется в главном конфигурационном файле Apache.

Решение

Как сказал Винко,

и посмотрите на этот файл.

В противном случае вот код, который мы используем для перенаправления из zirconium.zrs.hr/~zatemas в zatemas.zrs.hr:

Я видел в интернете, что люди обнаруживают HTTPS, в первую очередь, глядя, является ли порт 443. документация mod_rewrite говорит, что переменная HTTPS должна быть включена или выключена, соответственно — я полагаю, вы делаете чтобы проверить, включен ли он.

Также следите за: Директивы для перезаписи URL не работают, если вы обращаетесь к файлам в домашнем каталоге пользователя — например, example.com/~username/. Это не должно беспокоить вас в соответствии с вашим сценарием, хотя. Мой код выше находится в конфигурации основного сервера, под раздел (точнее, в , но это специфично для Debian и объединяется в основной конфигурации).

Кэш браузера

Для начала проверим активен ли кэш браузера на сайте, переходим на сервис webpagetest, вводим в поле url главной страницы и находим start scan.

Проверка функций блога

Ждем процесса проверки и смотрим на результаты. Ищем строчку Leverage browser caching и определяем кэшируются ли документы. В моем случае да, исключение – метрика, аналитика и vk, на них повлиять нельзя.

Есть ли кеш браузера

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

Gzip сжатие

Gzip сжатие потеряло актуальность при появлении AMP и Турбо страниц, но пользоваться ими нужно. Проверяем тем же сервисом webpagetest, только ищем строчку “Use gzip compression for transferring compressable responses”.

Наличие gzip сжатия

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

Такими встроенными возможностями обладают большинство провайдеров, например:

Beget
Timeweb
Masterhost

Для безопасности и защиты wp-config

В 99,9% проблемы нет, но перестраховаться стоит. Заходим на сайт и приписываем к адресу , смотрим что выдает браузер.

Отображение wp-config

Должна открыться пустая страница или произойти 301 переадресация на главную. Если покажется код документа, то нужно срочно его закрывать, просим помощи в поддержке, или прописываем вот такой текст.

Почему файл конфигураций htaccess для серверов Apache не работает

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

Обычно, эта ошибка связана с тем, что в конфигурациях сервера Apache ничего не сказано о htaccess. Хоть этот файл и используют повсеместно, не все хостинг-провайдеры подготавливают условия для того, чтобы вы могли им спокойно пользоваться. Тогда вам нужно самостоятельно настроить его. Для этого отыщите на сервере файл главных конфигураций Apache, который называется httpd.conf. В нем вам нужно отыскать тег . Внутри этого тега будет прописан путь к определенному каталогу, а также права для него. Вам нужно для каждого созданного файла htaccess прописывать новые теги .

Конфигурационный документ htaccess не запускается из-за того, что по умолчанию на сервере может быть прописан запрет на выполнение директив внутри него. За это отвечает опция AllowOverride. Если возле нее написано None, то конфигурационный файл не сможет заработать в каталоге. Вам нужно прописать All. Кроме того, вам нужно поставить открытые права на каталог с htaccess: Allow from all. Уже после этого, когда сохраните изменения в конфигурациях, htaccess должен заработать.

Если по каким-то причинам вы изменили уровень доступа к каталогу, и указали параметр All, но изменения не вступили в силу, и выскакивает ошибка 500, значит вы сделали что-то не так внутри htaccess. Придется проверять это вручную. Для этого закомментируйте все строчки. Чтобы это сделать, поставьте решетку «#» слева от каждой строки, без пробелов. Потом постепенно ставьте пробел меду решеткой каждой строки (то есть директивы), и смотрите на реакцию сайта. Если после того, как вы поставите пробел возле какой-то строки, вновь появится ошибка, значит данную директиву вы неправильно оформили. Синтаксис htaccess не прост, потому вам понадобится время, чтобы освоиться и научиться писать директивы без ошибок.

Кэширование в htaccess

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

Сначала активируем модуль и устанавливаем период кэширования по умолчанию:

Теперь мы можем настроить кэширование для каждого mime типа файлов:

В первой строке мы указываем, что страницы html нужно считать годными на один месяц 15 дней и два часа с момента загрузки. Доступны такие типы файлов:

image/x-icon;
image/jpeg;
image/png;
image/gif;
application/x-shockwave-flash;
text/css;
text/javascript;
application/javascript;
application/x-javascript;
text/html;
application/xhtml+xml;

Чтобы быть уверенным что эта конструкция не вызовет ошибок заключите ее в if:

What they are/How to use them

files (or «distributed configuration files»)
provide a way to make configuration changes on a per-directory basis. A
file, containing one or more configuration directives, is placed in a
particular document directory, and the directives apply to that
directory, and all subdirectories thereof.

Note:

If you want to call your file something
else, you can change the name of the file using the directive. For example,
if you would rather call the file then you
can put the following in your server configuration file:

In general, files use the same syntax as
the . What you can put in these files is determined by the
directive. This
directive specifies, in categories, what directives will be
honored if they are found in a file. If a
directive is permitted in a file, the
documentation for that directive will contain an Override section,
specifying what value must be in in order for that
directive to be permitted.

For example, if you look at the documentation for the
directive, you will find that it is permitted in
files. (See the Context line in the directive summary.) The line reads
. Thus, you must have at least
in order for this directive to be
honored in files.

Синтаксис файла htaccess

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

Все директивы из файла htaccess выполняются точно так же, как если бы они были размещены в глобальном конфигурационном файле, только внутри директивы <Directory адрес_папки_htaccess>. Это не позволяет менять глобальные настройки, но вы можете очень тонко настроить поведение программы в папках, к которым у вас есть права доступа.

Общий синтаксис директив очень прост, это пары команд и их опций, разделенных пробелом, например:

Команда параметр1 параметр2 флаги

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

Особенность переадресации на синонимах

Предположим, есть домен domain1.tld и синоним domain2.tld. Если запросить в браузере адрес //domain2.tld/dir/ со знаком слэша в конце, то будет отображена индексная страница из директории dir основного домена, при этом содержимое адресной строки браузера останется без изменений. Но если запросить //domain2.tld/dir без слэша в конце, то произойдёт переадресация на //domain1.tld/dir/, и содержимое адресной строки изменится соответствующим образом.

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

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

О создании переадресаций с другими условиями вы можете узнать из документации по web-серверу Apache.

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

Раньше веб-разработчикам приходилось на Windows-машине устанавливать сервер Apache с различными дополнениями к нему: PHP, Perl, MySQL и т.д. — в целях более удобной отладки сайтов. Но Дмитрий Котеров и группа программистов упростила жизнь многим веб-разработчикам, создав проект «Денвер».

Я уже давно использую Denwer (Джентельменский набор веб-разработчика). Он меня полностью устраивает, потому что этот набор прост в установке и не прихотлив в использовании.

Стандартный пакет Денвера включает в себя следующий пакет:

Инсталлятор (поддерживается также инсталляция на flash-накопитель).
Apache, SSL, SSI, mod_rewrite, mod_php.
PHP5 с поддержкой GD, MySQL, sqLite.
MySQL5 с поддержкой транзакций.
Система управления виртуальными хостами, основанная на шаблонах. Чтобы создать новый хост, вам нужно лишь добавить директорию в каталог /home, править конфигурационные файлы не требуется. По умолчанию уже поддерживаются схемы именования директорий многих популярных хостеров; новые можно без труда добавить.
Система управления запуском и завершением всех компонентов Денвера.
phpMyAdmin — система управления MySQL через Web-интерфейс.
Эмулятор sendmail и SMTP-сервера (отладочная «заглушка» на localhost:25, складывающая приходящие письма в /tmp в формате .eml); поддерживается работа совместно с PHP, Perl, Parser и т.д.

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

Другие решения

В моем случае я изменил в httpd.conf:

и это работает.

Два небольших отличия от других ответов:

обратная ссылка в берет из последнего подобранного , так что проверка на HTTPS должна прийти до проверка на www в имени хоста.

косая черта в середине не нужна, потому что вы получите это из соответствия пути в ,

Последний совет: так как у вас есть контроль над разделы в основной конфигурации Apache, было бы быстрее поставить эти правила там. Кроме того, вы должны разделить их, поместив обычный HTTP в *: 80 и HTTPS в *: 443, что означает, что вы можете удалить полностью, поскольку он будет применяться только к запросам, предназначенным для этого виртуального хоста.

Похоже, вы говорите, что ваш mod_rewrite не работает вообще. Вот несколько вещей, чтобы попробовать:

Вы сказали, что это было включено, но предоставили информацию:

Просто показывает его в папке «mods-available», что означает, что он установлен, но не обязательно включен. Если он включен, он должен быть символической ссылки в папке «mods-enabled» (вам нужно a2enmod это если его там нет)

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

Отредактировано, чтобы добавить: Вы можете переместить мод переписать в базовый конфиг. Если у вас есть доступ к нему, рекомендуется в любом случае поместить ваш конфиг в базовый раздел (см. Вот). Также легче определить, имеет ли он какое-либо отношение к mod_rewrite (как, например, ваши allowoverrides путаются) или это просто проблема htaccess.

Держа на: (@Vinko Vrsalovic прав в том, что это жесткий отладочный носитель) Если вы переместили его в базовую конфигурацию, и он все еще не работал, то мы находимся на чем-то, вы исключили часть .htaccess. Вы должны опубликовать новую конфигурацию, а также переписать журналы. Если вы не получили журнал перезаписи, то 1) ваша конфигурация не была загружена (необходимо перезапустить apache) или 2) вы не попали в раздел конфигурации, который вы считаете

Прежде всего, убедитесь, что mod_rewrite действительно загружается. Вы можете сделать это с помощью apache2ctl:

Если это не так, вам, возможно, придется запустить ‘a2enmod rewrite’

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

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

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

У меня была та же самая проблема, и это потратило впустую мои 5 часов, чтобы исправить.

Итак, чтобы использовать mod_rewrite, вы можете ввести следующую команду в терминале:

Затем перезапустите свой Apache.

Когда (не) использовать файлы .htaccess

Если коротко, вы должны использовать файлы .htaccess только когда у вас нет доступа к главному конфигурационному файлу сервера. Как уже было отмечено, распространены неправильные мнения, что аутентификацию пользователей и директивы mod_rewrite можно указывать только в .htaccess. Это просто неверно. Конфигурации аутентификации можно поместить в главную конфигурацию сервера и, на самом деле, это более предпочтительный вариант. Аналогично директивы mod_rewrite в главной конфигурации сервера работают лучше по многим причинам.

Файлы .htaccess должны использоваться в случае, когда веб-мастеру нужно применить изменённые настройки к серверу на уровне директорий, но у него нет root доступа к системе сервера. Это обычный случай для виртуальных хостингов, то есть на практике очень часто файлы .htaccess являются единственной возможной альтернативой.

Тем не менее, в целом использование файлов .htaccess следует избегать когда это возможно. Любые настройки, которые вы собираетесь разместить в файле .htaccess, могут быть эффективно сделаны в разделе <Directory> в главном конфигурационном файле сервера.

Имеется две главные причины избежания использования файлов .htaccess.

Первая причина — это производительность. Когда AllowOverride установлена на разрешение использования файлов .htaccess, httpd будет искать файлы .htaccess в каждой папке. То есть разрешение файлов .htaccess ударяет по производительности не зависимо от того, используете вы на самом деле .htaccess или нет, создали вы хоть один файл .htaccess или нет. Файл .htaccess загружается каждый раз, когда запрашивается документ.

Более того, помните, что httpd должен искать файлы .htaccess в директориях более высокого уровня чтобы собрать полный набор директив, которые должны быть применены. Таким образом, если файл запрошен из директории /www/htdocs/example, то httpd должен искать эти файлы в:

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess

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

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

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

Помещение файла .htaccess с управляющими директивами в папку /www/htdocs/example эквивалентно помещению этих же директив в раздел Directory: <Directory «/www/htdocs/example»> в главных настройках конфигурации сервера:

Содержимое файла .htaccess в /www/htdocs/example

AddType text/example ".exm"

Секция из файла httpd.conf:

<Directory "/www/htdocs/example">
    AddType text/example ".exm"
</Directory>

При этом размещение этой конфигурации в файле настроек сервера приведёт в результате к меньшему влиянию на производительность, поскольку конфигурация загружается только один раз при запуске httpd, а не при каждом запросе к файлу.

Можно полностью отключить использование файлов .htaccess установив директиву AllowOverride на none:

AllowOverride None

Настройка SELinux для web сервера apache

Раздел для тех, кто хочет настроить SELinux на своем web сервере. Сначала ставим пакет policycoreutils-python-utils если он еще не установлен. Он нам нужен для утилиты semanage.

# dnf install policycoreutils-python-utils

Теперь автоматически сформируем модуль для selinux на основе событий аудита, которые накопились, пока мы настраивали сайт. Посмотреть их можно командой.

# grep httpd /var/log/audit/audit.log | audit2why

Создаем модуль selinux.

# grep httpd /var/log/audit/audit.log | audit2allow -M my-httpd

Загружаем его.

# semodule -i my-httpd.pp

То же самое делаем для php.

# grep php /var/log/audit/audit.log | audit2allow -M my-php
# semodule -i my-php.pp

Добавим нашу директорию /web/sites в соответствующие таблицы selinux для контента и логов.

# semanage fcontext -a -t httpd_sys_content_t "/web/sites(/.*)?"
# semanage fcontext -a -t httpd_log_t "/web/sites(/.*)?/log(/.*)?"

И отдельно добавим каталог, куда web сервер сможет писать данные. Я покажу на примере правила для сайтов wordpress, где web сервер должен уметь писать в директорию wp-content для загрузки медиафайлов, установки тем и плагинов, а так же изменять файл wp-config.php.

# semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-content(/.\*)?"
# semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-config.php"

Обновляем атрибуты файлов новым контекстом SELinux.

# restorecon -Rv /web/sites

В завершении настройки selinux для apache, добавим еще один параметр, без которого httpd не сможет писать файлы в указанные каталоги.

# setsebool -P httpd_unified 1

Теперь активируем защиту selinux и проверяем, что она работает.

# setenforce 1
# getenforce
Enforcing

Режим работы Enforcing означает, что selinux работает. Убедиться, что модули загружены, можно командой.

# semodule -l | grep my-

В целом, по selinux все. Мы просто разрешили все, что веб сервер просил. По идее, надо вдумчиво во всех правилах разбираться и разрешать только то, что считаешь нужным. Я честно скажу, что selinux знаю не очень хорошо. Дальше загрузки готовых модулей и автоматического создания модулей с помощью audit2allow я не двигался. Руками модули никогда не писал. Если есть какой-то более осмысленный и правильный способ настройки selinux на кастомной конфигурации веб сервера, буду рад полезной информации.

Хорошая практическая статья по ручной настройке selinux для web сервера — https://habr.com/ru/post/322904/. Там же есть ссылки на другие статьи автора на тему selinux. Написано содержательно и наглядно, рекомендую для тех, кто будет знакомиться с технологией.

Редирект

Эти директивы используются с завидной регулярностью. Они позволяют перенаправить посетителя со старого URL на новую страницу. Это возможно благодаря 301-редиректу. Достаточно в код файла вписать:

Redirect 301 /index.html http://domain.ru/newindex.html

В целом директива будет отображена в таком виде:

Redirect  URL_LOCAL URL_REDIRECT

URL_LOCAL – это старый адрес, с которого осуществляется перенос пользователя.

URL_REDIRECT – новый URL, куда переносится страница.

В поле могут быть следующие значения:

301 – страница перенесена навсегда.
302 – страница перенесена на время.
303 – смотрите другую страницу.
410 – страница удалена.

Как должен выглядеть правильный htaccess

В итоге правильный код htaccess должен выглядеть так:

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

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

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