Если файл htaccess находится в одной из директорий сайта, то действие его директив распространяется на

Обновлено: 29.06.2024

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

Некоторые веб-сайты временно сохранят устаревшую поддержку .htaccess. Узнайте больше здесь.

Что такое файл .htaccess и почему он устарел?

Серверы Apache используются для выполнения PHP-кода, на котором работает WordPress. .htaccess — это файл конфигурации Apache, который веб-администратор может использовать, чтобы указать Apache, как взаимодействовать с веб-сайтом. Он может контролировать любое количество вещей на каждом сайте, например, как формируются ваши URL-адреса или ограничивать доступ к каталогу.

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

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

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

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

Некоторые веб-сайты временно сохранят устаревшую поддержку .htaccess. Узнайте больше здесь.

Директивы WordPress .htaccess по умолчанию

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

Перезаписи WordPress по умолчанию будут обрабатываться WP Engine непосредственно с уровня сервера Apache. Таким образом, если ваши файлы .htaccess выглядят как-либо из перечисленных ниже, это прекращение поддержки не повлияет на ваш веб-сайт.

Вордпресс по умолчанию .htaccess

Многосайтовый субдомен .htaccess

Подкаталог Multisite .htaccess

Директивы и альтернативы

Если на вашем сайте используются директивы .htaccess, выходящие за рамки правил WordPress по умолчанию (см. выше), мы составили список рекомендуемых альтернатив.

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

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

Используйте плагин.

Нет
Статические ресурсы обслуживаются Nginx, а не Apache (где будет обрабатываться .htaccess).

Нет
По умолчанию WP Engine уже запрещает индексирование каталогов.

Заголовки следует отправлять с кодом PHP.

Статические ресурсы обслуживаются Nginx, а не Apache (где будет обрабатываться .htaccess).
Если нужны дополнительные правила, их можно добавить в конфигурацию Nginx, обратившись в службу поддержки.

По умолчанию WP Engine управляет правилами кэширования на уровне сервера.
Дополнительными правилами кэширования можно управлять в коде PHP.
Дополнительные правила кэширования для статических ресурсов можно применить к Nginx, обратившись в службу поддержки.

Подключаемые модули WordPress часто добавляют правила безопасности в файл .htaccess. WP Engine уже применяет эти правила по умолчанию на уровне сервера.
Плагины должны обрабатывать дополнительные директивы в своем PHP-коде.

Обработка перенаправлений 301 и 302

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

Менее 1000 переадресаций

Перенаправления можно добавить в конфигурацию Nginx WP Engine
Массовый импорт перенаправлений, обратившись в службу поддержки WP Engine

Более 1000 переадресаций

Импорт перенаправлений в конфигурацию WP Engine Nginx будет неэффективен при таком количестве из-за раздувания и накладных расходов.
Мы рекомендуем загружать перенаправления в подключаемый модуль Redirection или, если вы используете Yoast SEO, управлять перенаправлениями в Yoast Premium.

Массовый перенос перенаправлений из файла .htaccess

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

Веб-правила

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

Эта страница позволяет блокировать/разрешать IP-адреса, ограничивать трафик на основе заголовка или управлять трафиком по типу запроса. Все веб-сайты на WP Engine автоматически включают эту страницу веб-правил.

Устаревшие обновления

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

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

Включение веб-правил отключает поддержку .htaccess.
Включение поддержки .htaccess отключает все веб-правила.
Для устранения неполадок можно одновременно отключить как веб-правила, так и поддержку .htaccess.

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

Мы рекомендуем перенести правила из .htaccess на страницу веб-правил как можно скорее.

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

Файлы .htaccess
Что это такое/как их использовать
Когда (не) использовать файлы .htaccess
Как применяются директивы
Пример аутентификации
Пример включения на стороне сервера
Переписать правила в файлах .htaccess
Пример компьютерной графики
Устранение неполадок

См. также

файлы .htaccess

Что это такое/Как их использовать

Файлы .htaccess (или «распределенные файлы конфигурации») позволяют вносить изменения в конфигурацию для каждого каталога. Файл, содержащий одну или несколько директив конфигурации, помещается в определенный каталог документов, и директивы применяются к этому каталогу и всем его подкаталогам.

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

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

Например, если вы посмотрите документацию по директиве AddDefaultCharset, вы обнаружите, что она разрешена в файлах .htaccess. (См. строку Context в сводке директив.) Строка Override читается как FileInfo. Таким образом, вы должны иметь как минимум AllowOverride FileInfo, чтобы эта директива соблюдалась в файлах .htaccess.

Пример:

Контекст:	конфигурация сервера, виртуальный хост, каталог, .htaccess
Переопределение:	Информация о файле

Если вы не уверены, разрешена ли конкретная директива в файле .htaccess, просмотрите документацию по этой директиве и проверьте строку Context на наличие ".htaccess".

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

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

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

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

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

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

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

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

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

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

Файл .htaccess в /www/htdocs/example :

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

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

Как применяются директивы

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

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

(Примечание. Чтобы разрешить использование директивы "Options" в файлах .htaccess, у вас должны быть активированы "AllowOverride Options".)

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

Из-за этого второго файла .htaccess в каталоге /www/htdocs/example1/example2 выполнение CGI не разрешено, так как действует только параметр «Включает параметры», который полностью переопределяет любые более ранние настройки, которые могли быть на месте.

Объединение .htaccess с основными файлами конфигурации

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

Пример аутентификации

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

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

Содержимое файла .htaccess:

Обратите внимание, что для того, чтобы эти директивы имели какой-либо эффект, должен быть активирован параметр AllowOverride AuthConfig.

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

Пример включения на стороне сервера

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

Обратите внимание, что параметры AllowOverride и AllowOverride FileInfo должны быть активны, чтобы эти директивы имели какой-либо эффект.

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

Переписать правила в файлах .htaccess

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

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

Дополнительные сведения об использовании mod_rewrite см. в документации по mod_rewrite .

Пример компьютерной графики

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

В качестве альтернативы, если вы хотите, чтобы все файлы в данном каталоге считались программами CGI, это можно сделать со следующей конфигурацией:

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

Устранение неполадок

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

В большинстве случаев проблема заключается в том, что параметр AllowOverride не установлен таким образом, чтобы соблюдались директивы вашей конфигурации. Убедитесь, что у вас нет действия AllowOverride None для рассматриваемой области файла. Хороший тест для этого — поместить мусор в файл .htaccess и перезагрузить страницу. Если ошибка сервера не генерируется, то почти наверняка у вас включен параметр AllowOverride None.

[Пятница, 17 сентября, 18:43:16 2010] [предупреждение] [клиент 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex здесь запрещен

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

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

[Сб, 09 августа, 16:22:34 2008] [предупреждение] [клиент 192.168.200.51] /var/www/html/.htaccess: RewriteCond: неверные разделители флагов

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

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

Общее использование файла .htaccess

Файл .htaccess имеет несколько вариантов использования. Наиболее распространенные примеры включают:

В облаке

Когда не следует использовать .htaccess?

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

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

/.htaccess
/public_html/.htaccess
/public_html/test_web/.htaccess
/public_html/test_web/content/.htaccess

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

Включить файл .htaccess

Чтобы включить файл .htaccess, у вас должны быть права sudo/root на сервере.

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

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

URL-адреса перенаправления

Если вы хотите просто перенаправить один URL-адрес на другой, лучше всего использовать директиву Redirect. Всякий раз, когда от клиента поступает запрос по старому URL-адресу, он перенаправляет его на новый URL-адрес в новом месте.

Если вы хотите выполнить полное перенаправление на другой домен, вы можете установить следующее:

Если вы просто хотите перенаправить старый URL-адрес на новый URL-адрес на том же хосте:

Кубернеты и OpenShift

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

Чтобы создать пользовательскую страницу 404, просто создайте веб-страницу, которая будет работать как страница 404, а затем добавьте следующий код в файл .htaccess:

Вы должны изменить /error/pagenotfound.html на местоположение вашей страницы 404.

Пройдемся по каждой строке.

RewriteEngine on включает модуль RewriteEngine. Это необходимо; в противном случае условия и правила не будут работать.

Первое условие проверяет, введен ли www. [OR, NC] означает без регистра, что означает, что даже если введенный URL содержит сочетание букв верхнего или нижнего регистра.

Подведение итогов

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

Файлы Apache .htaccess позволяют пользователям настраивать каталоги веб-сервера, которыми они управляют, без изменения основного файла конфигурации.

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

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

Перенаправления

Иногда нам нужно сообщить пользователям, что ресурс временно или постоянно перемещен. Именно для этого мы используем Redirect и RedirectMatch.

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

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

Возвращает временный статус перенаправления (302). Это значение по умолчанию.

Возвращает статус "Просмотреть другое" (303), указывающий, что ресурс был заменен.

Возвращает статус "Исключен" (410), указывающий, что ресурс был окончательно удален. При использовании этого статуса аргумент URL следует опустить.

Независимые ресурсы

Общий доступ к CORS

Эта директива добавит заголовок CORS для всех ресурсов в каталоге с любого веб-сайта.

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

Изображения из разных источников

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

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

В руководстве по устранению неполадок Google Fonts в Google Chrome сообщается, что, хотя Google Fonts может отправлять заголовок CORS с каждым ответом, некоторые прокси-серверы могут удалять его до того, как браузер сможет использовать его для отображения шрифта.

Время ресурсов из разных источников

Спецификация Resource Timing Level 1 определяет интерфейс для веб-приложений для доступа к полной информации о времени для ресурсов в документе.

Заголовок ответа Timing-Allow-Origin указывает источники, которым разрешено просматривать значения атрибутов, полученные с помощью функций Resource Timing API, которые в противном случае были бы сообщены как нулевые из-за ограничений между источниками.

Если ресурс не обслуживается с Timing-Allow-Origin или если заголовок не включает источник, делающий запрос, некоторые из атрибутов объекта PerformanceResourceTiming будут установлены в ноль.

Пользовательские страницы/сообщения об ошибках

Apache позволяет предоставлять пользователям настраиваемые страницы ошибок в зависимости от типа получаемой ими ошибки.

Страницы ошибок представлены в виде URL-адресов. Эти URL-адреса могут начинаться с косой черты (/) для локальных веб-путей (относительно DocumentRoot) или представлять собой полный URL-адрес, который может разрешить клиент.

Предотвращение ошибок

Этот параметр влияет на работу MultiViews для каталога, к которому применяется конфигурация.

Эффект MultiViews следующий: если сервер получает запрос на /some/dir/foo, если для /some/dir включено MultiViews, а /some/dir/foo не существует, то сервер считывает каталог ищет файлы с именем foo.* и эффективно подделывает карту типов, которая называет все эти файлы, назначая им те же типы мультимедиа и кодировки контента, которые были бы, если бы клиент запросил один из них по имени. Затем он выбирает наилучшее соответствие требованиям клиента.

Этот параметр отключает MultiViews для каталога, к которому применяется эта конфигурация, и предотвращает возврат Apache ошибки 404 в результате перезаписи, когда каталог с таким именем не существует

Типы мультимедиа и кодировки символов

Изменение метаданных файла не меняет значение заголовка Last-Modified. Таким образом, ранее кэшированные копии могут по-прежнему использоваться клиентом или прокси с предыдущими заголовками. Если вы измените метаданные (язык, тип контента, набор символов или кодировку), вам может потребоваться «прикоснуться» к затронутым файлам (обновив дату их последнего изменения), чтобы гарантировать, что все посетители получат исправленные заголовки контента.

Обслуживать ресурсы с правильными типами мультимедиа (например, типами MIME)

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

Серверы должны использовать текст/javascript для ресурсов JavaScript, как указано в спецификации HTML

Установите атрибут Charset по умолчанию

Каждый фрагмент контента в Интернете имеет набор символов. Большинство, если не все, содержимое представлено в формате Unicode UTF-8.

Используйте AddDefaultCharset для обслуживания всех ресурсов, помеченных как text/html или text/plain с кодировкой UTF-8.

Установите кодировку для определенных типов мультимедиа

Обслуживайте следующие типы файлов с параметром charset, установленным на `UTF-8`, используя директиву AddCharset, доступную в mod_mime.

Mod_rewrite и директивы RewriteEngine

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

Включить mod_rewrite

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

Вы не должны дублировать контент в нескольких источниках (с www и без него); это может вызвать проблемы SEO (дублированный контент), поэтому вам следует выбрать один из вариантов и перенаправить другой. Вы также должны использовать канонические URL-адреса, чтобы указать, какие URL-адреса должны сканировать поисковые системы (если они поддерживают эту функцию).

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

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

Параметры фрейма

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

Возможно, это не лучшая настройка для всех. Вы должны прочитать о двух других возможных значениях для заголовка X-Frame-Options: SAMEORIGIN и ALLOW-FROM .

Хотя вы можете отправить заголовок X-Frame-Options для всех страниц вашего веб-сайта, у этого есть потенциальный недостаток, заключающийся в том, что он запрещает даже любое кадрирование вашего контента (например, когда пользователи посещают ваш веб-сайт, используя страницу результатов поиска картинок Google). ).

Тем не менее, вы должны убедиться, что вы отправляете заголовок X-Frame-Options для всех страниц, которые позволяют пользователю выполнять операцию изменения состояния (например, страницы, содержащие ссылки для покупки в один клик, оформления заказа или банковского перевода). страницы подтверждения, страницы, которые вносят постоянные изменения в конфигурацию и т. д.).

Политика безопасности контента (CSP)

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

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

Пример политики ниже:

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

Доступ к каталогу

Эта директива предотвратит доступ к каталогам, в которых нет файла индекса в любом формате, который настроен на сервере, например index.html или index.php .

Заблокировать доступ к скрытым файлам и каталогам

В системах Macintosh и Linux файлы, начинающиеся с точки, скрыты от просмотра, но не от доступа, если вы знаете их имя и местоположение. Эти типы файлов обычно содержат пользовательские настройки или сохраненное состояние утилиты и могут включать в себя довольно личные места, такие как, например, каталоги .git или .svn.

Каталог .well-known/ представляет собой стандартный (RFC 5785) префикс пути для «известных местоположений» (например: /.well-known/manifest.json , /.well-known/keybase.txt ). и поэтому доступ к его видимому контенту не должен быть заблокирован.

Заблокировать доступ к файлам с конфиденциальной информацией

Заблокируйте доступ к резервным и исходным файлам, которые могут быть оставлены некоторыми текстовыми редакторами и могут представлять угрозу безопасности, если кто-либо имеет к ним доступ.

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

Запретить некоторым браузерам прослушивание ответа MIME

Ограничивает все выборки по умолчанию источником текущего веб-сайта, устанавливая для директивы default-src значение 'self', что действует как резерв для всех директив Fetch.
- Это удобно, так как вам не нужно указывать все директивы Fetch, применимые к вашему сайту, например: connect-src 'self'; шрифт-источник 'я'; сценарий-источник 'я'; style-src 'self' и т. д.
- Это ограничение также означает, что вы должны явно указать, с каких сайтов ваш веб-сайт может загружать ресурсы, иначе он будет ограничен тем же источником, что и страница, отправляющая запрос.
Запрещает элемент на веб-сайте. Это делается для того, чтобы злоумышленники не могли изменить расположение ресурсов, загружаемых с относительных URL-адресов
- Если вы хотите использовать этот элемент, используйте вместо него base-uri 'self'
Разрешить отправку форм только из текущего источника с помощью: form-action 'self'
Запрещает всем веб-сайтам (включая ваш собственный) встраивать ваши веб-страницы, например, в элемент или, установив: frame-ancestors 'none' .
- Директива frame-ancestors помогает избежать атак с использованием кликджекинга и аналогична заголовку X-Frame-Options.
- Браузеры, поддерживающие заголовок CSP, будут игнорировать X-Frame-Options, если также указаны предки кадров
Заставляет браузер обрабатывать все ресурсы, которые обслуживаются через HTTP, как если бы они были безопасно загружены через HTTPS, устанавливая директиву upgrade-insecure-requests
- upgrade-insecure-requests не гарантирует HTTPS для навигации верхнего уровня. Если вы хотите, чтобы сам веб-сайт загружался через HTTPS, вы должны включить заголовок Strict-Transport-Security
Включает заголовок Content-Security-Policy во все ответы, способные выполнять сценарии. Сюда входят часто используемые типы файлов: документы HTML, XML и PDF. Хотя файлы Javascript не могут выполнять сценарии в «контексте просмотра», они включены для целевых веб-воркеров.

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

Политика реферала

Мы включаем заголовок Referrer-Policy в ответы для ресурсов, которые могут запрашивать (или переходить) к другим ресурсам.

Сюда входят часто используемые типы ресурсов: HTML, CSS, XML/SVG, документы PDF, сценарии и рабочие процессы.

Чтобы полностью предотвратить утечку реферера, вместо этого укажите значение no-referrer. Обратите внимание, что это может отрицательно сказаться на инструментах аналитики.

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

Метод TRACE, хотя и кажется безвредным, в некоторых сценариях может быть успешно использован для кражи учетных данных законных пользователей. См. Атака с межсайтовым отслеживанием (XST) и Руководство по тестированию веб-безопасности OWASP

Современные браузеры теперь предотвращают запросы TRACE, сделанные через JavaScript, однако были обнаружены другие способы отправки запросов TRACE с помощью браузеров, например с использованием Java.

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

Удалить заголовок ответа X-Powered-By

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

По возможности отключите заголовок X-Powered-By на уровне языка/фреймворка (например, для PHP это можно сделать, установив в php.ini следующее.

Удалить нижний колонтитул с информацией о сервере, созданный Apache

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

Исправить неработающие заголовки AcceptEncoding

Сжатие типов мультимедиа

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

Сопоставление расширений с типами мультимедиа

Сопоставьте следующие расширения имен файлов с указанным типом кодировки с помощью AddEncoding, чтобы Apache мог обслуживать типы файлов с соответствующим заголовком ответа Content-Encoding (это НЕ заставит Apache их сжимать!). Если эти типы файлов будут обслуживаться без соответствующего заголовка ответа Content-Encoding, клиентские приложения (например, браузеры) не будут знать, что им сначала нужно распаковать ответ, и, следовательно, не смогут понять содержимое.< /p>

Срок действия кэша

Обслуживайте ресурсы с отдаленной датой истечения срока действия, используя модуль mod_expires и заголовки Cache-Control и Expires.

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

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

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

Что нужно знать

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

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

Второе: безопасность — файл .htaccess гораздо более доступен, чем стандартная конфигурация Apache, и изменения вступают в силу мгновенно (без необходимости перезапуска сервера). Предоставление пользователям разрешения на внесение изменений в файл .htaccess дает им большой контроль над самим сервером. Любая директива, размещенная в файле .htaccess, имеет тот же эффект, что и в самой конфигурации apache.

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

Покончив с этим, давайте перейдем к информации .htaccess.

Как активировать файл .htaccess

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

Оказавшись внутри этого файла, найдите следующий раздел и измените строку с надписью AllowOverride с None на All. Теперь раздел должен выглядеть так:

После сохранения и выхода из этого файла перезапустите apache.

Создание файла .htaccess:

Пять распространенных вариантов использования страницы .htaccess

<р>1. Mod_Rewrite: один из самых полезных аспектов .htaccess файл mod_rewrite. Вы можете использовать пространство в файле .htaccess, чтобы указать и изменить способ отображения URL-адресов и веб-страниц на ваших сайтах для ваших пользователей. Полное руководство о том, как это сделать, можно найти здесь.

<р>2. Аутентификация: хотя использование файла .htaccess не требует столько разрешений, сколько потребовалось бы для доступа к файлу apache2.conf, мы все же можем вносить эффективные изменения на сайт. После такого изменения требуется пароль для доступа к определенным разделам веб-страницы.

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

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

Вы можете использовать этот полезный сайт для создания пары имени пользователя и зашифрованного пароля. Если имя пользователя вашего авторизованного пользователя — jsmith, а пароль — «awesome», пара будет выглядеть так: jsmith:VtweQU73iyETM. Вы можете вставить столько строк, сколько необходимо, в файл .htpasswd, но убедитесь, что каждый пользователь получает свою собственную строку.

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

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

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

В этом руководстве я собираюсь создать страницу 404. Однако вы можете заменить эту ошибку чем угодно:

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

Имейте в виду, что Apache ищет страницу 404, расположенную в корне сайта. Если вы разместили новую страницу с ошибкой в более глубоком подкаталоге, вам нужно включить ее в строку, чтобы она выглядела примерно так:

<р>4. Типы MIME. Если на вашем сайте есть файлы приложений, для доставки которых ваш сервер не настроен, вы можете добавить типы MIME на сервер Apache в файле .htaccess с помощью следующего кода.

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

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

Чтобы включить SSI, введите следующий код в файл .htaccess.

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

Однако, если у вас есть много страниц .html, которые вы не хотите переименовывать с расширениями .shtml, вы можете использовать другую тактику для их анализа на наличие команд SSI — XBitHack.

Добавление этой строки в файл .htaccess заставляет Apache проверять все файлы html с соответствующими разрешениями для включения на стороне сервера.

Чтобы сделать страницу подходящей для XBitHack, используйте эту команду:

Подробнее

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

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

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

Читайте также: