Как удалить слэш в каталоге WordPress

Вопрос или проблема

Я установил веб-сайт в каталоге своего домена, например, example.com/website.

Главная проблема в том, что он перенаправляет меня на example.com/website/.

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

Я хочу, чтобы пользователь мог зайти на мой веб-сайт без последней косой черты, то есть example.com/website.

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

Я прочитал много статей и даже вопросы пользователей на Stack Exchange, связанные с завершающей косой чертой, но это не помогло.

Также я пробовал различные коды .htaccess, но это не помогло.

Пожалуйста, помогите мне с этим.

Основная проблема в том, что он перенаправляет меня на example.com/website/

По умолчанию Apache (mod_dir) «исправляет» URL, выполняя перенаправление 301, чтобы добавить завершающую косую черту, если она пропущена в каталоге файловой системы. Это необходимо для правильного функционирования других функций Apache…

  • без завершающей косой черты документ DirectoryIndex не будет обслуживаться, и вернется ответ 403 Forbidden (если только Options Indexes не включен, в этом случае вы получите список каталогов, несмотря на наличие индексного документа – потенциальная уязвимость безопасности, см. ниже).

  • Если запрос – /website (без завершающей косой черты), то директивы mod_rewrite в файле /website/.htaccess не будут выполнены (поэтому фронт-контроллер WordPress не сработает).

Можно предотвратить добавление Apache (mod_dir) завершающей косой черты к каталогу /website (используя DirectorySlash Off), однако затем нужно будет предпринять дополнительные шаги, чтобы обойти вышеупомянутые проблемы и вручную добавить завершающую косую черту (или переписать URL напрямую к фронт-контроллеру WP) с внутренним переписыванием. Это нельзя сделать из файла /website/.htaccess – это необходимо переместить в корень документа (родительский каталог).

Например:

  1. Переместите уже существующий файл WordPress /website/.htaccess в родительский каталог (корень документа), то есть /.htaccess.

  2. Затем необходимо внести такие изменения в файл /.htaccess и фронт-контроллер WordPress:

# mod_autoindex должен быть отключен
# Иначе ваш сайт будет уязвим к "раскрытию информации"
Options -Indexes

# Предотвратить добавление mod_dir завершающей косой черты к каталогам файловой системы
DirectorySlash Off

# BEGIN WordPress
RewriteEngine On
RewriteBase /website

# Удалить завершающую косую черту из "/website/", если обратиться напрямую
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^(website)/$ /$1 [R=301,L]

# Направляем запросы для самого каталога (то есть "домашняя страница")
# (DirectoryIndex иначе не срабатывает.)
RewriteRule ^website/?$ index.php [L]

# Фронт-контроллер для всех других URL-ов вида "/website/<something>"
RewriteRule ^[^/]+/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^website/. index.php [L]
# END WordPress

Так как нам пришлось настраивать секцию # BEGIN WordPress, вы должны предотвратить перезапись WordPress этого и создания другого (по умолчанию) файла .htaccess в подкаталоге /website/.

Вышеописанное также канонизирует любые запросы для /website/ (с завершающей косой чертой) и перенаправляет на /website, чтобы убрать завершающую косую черту. Вы должны сначала протестировать с перенаправлением 302 (временное), чтобы избежать потенциальных проблем с кэшированием.

Вам нужно будет очистить кеш браузера перед тестированием, так как предыдущий 301 редирект (mod_dir/Apache) для добавления завершающей косой черты был сохранен в кэше браузера.

Обратите внимание, что директива DirectorySlash Off применяется ко всем подкаталогам. Поэтому, если какие-либо другие подкаталоги должны быть доступны (я думаю, маловероятно), вам нужно будет принять дополнительные меры.

Могу ли я сделать это с помощью функции PHP

Добавление завершающей косой черты не связано с PHP – это «функция» Apache. Однако, вам нужно убедиться, что WordPress все еще может маршрутизировать URL, так как запрашиваемый путь URL теперь /website, а не /website/ (который технически является другим URL).

Источник:

Предупреждение о безопасности
Отключение перенаправления с завершающей косой чертой может привести к
раскрытию информации. Рассмотрите ситуацию, когда mod_autoindex
активен (Options +Indexes), и DirectoryIndex настроен на
действительный ресурс (например, index.html), и нет другого
специального обработчика, определенного для этого URL. В этом случае
запрос с завершающей косой чертой покажет файл index.html. Но запрос
без завершающей косой черты приведет к отображению содержимого
каталога.

Ответ или решение

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

Теория

Apache добавляет завершающий слэш по следующим причинам:

  1. Безопасность и доступность:

    • Если у каталога /website отсутствует завершающий слэш, сервер может вернуть ответ 403 Forbidden, если конфигурация не предусматривает иное.
    • Без завершающего слэша модули, такие как mod_rewrite, определяют каталог как файл, и это может привести к неработоспособности механизмов, таких как "фронт-контроллер" в WordPress.
  2. Функции "index":

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

Пример

Для решения этой задачи потребуется внести изменения в файл .htaccess, что обеспечит:

  1. Отключение автоматического добавления слэша:

    • Использование DirectorySlash Off отключит автоматическое добавление слэша к URL, указывающим на каталог.
  2. Настройка перенаправления:

    • Перенаправление запросов, которые заканчиваются слэшом, на URL без него, используя правила mod_rewrite для корректного функционирования WordPress.

Пример корректировки файла .htaccess выглядит следующим образом:

# Отключаем отображение содержимого каталогов
Options -Indexes

# Отключаем добавление завершающего слэша
DirectorySlash Off

# Начало раздела WordPress
RewriteEngine On
RewriteBase /website

# Удаление завершающего слэша из "/website/", если запрашивается напрямую
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^(website)/$ /$1 [R=301,L]

# Маршрутизация запросов для самого каталога (то есть домашней страницы)
RewriteRule ^website/?$ index.php [L]

# Фронт-контроллер для всех остальных URL вида "/website/<что-то>"
RewriteRule ^[^/]+/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^website/. index.php [L]
# Конец раздела WordPress

Применение

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

  • Предотвращение перезаписи WordPress:

    • Убедитесь, что WordPress не перезаписывает ваш файл .htaccess, добавляя собственные правила, что может привести к нежелательным переадресациям.
  • Очистка кеша браузера:

    • Очистите кеш браузера перед тестированием изменений, так как предыдущие 301 перенаправления могли быть закэшированы.
  • Учтите последствия для подкаталогов:

    • DirectorySlash Off будет применено ко всем подкаталогам. Если какие-то из них должны быть доступны, необходимо будет настроить дополнительные правила.

Заключение:

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

Ссылки для дальнейшего изучения:

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

Оцените материал
Добавить комментарий

Капча загружается...