.htaccess как скрыть расширение php - PullRequest
Новая
       22

.htaccess как скрыть расширение php

0 голосов
/ 25 апреля 2020

Предположим, у меня есть файл .htaccess на wwwroot моего Apache сайта, скажем, www.example.com.

Я хочу добиться этого эффекта:

Когда пользователь вводит ссылку www.example.com/dashboard в браузере, он фактически отображает содержимое в www.example.com/dashboard.php

И если пользователь непосредственно вводит ссылку www.example.com/dashboard.php в браузере, он отображает ошибку.

Я попробовал следующий .htaccess код: 

RewriteEngine on

# this is to deny direct access of php files in browser
# that is, when the user input directly 'www.example.com/dashboard.php'
  it will turn to error
RewriteRule \.php$ - [F,L]


# if the link the user input to the browser does not end with .php,
  the code will go down ahead

# this rewrite 'www.example.com/dashboard' to 'www.example.com/dashboard.php'
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_FILENAME}.php [QSA,L,END]

Однако это также сделает www.example.com/dashboard недоступным из браузера.

Если я удаляю строку RewriteRule \.php$ - [F,L], все работает нормально, но пользователь все равно может ввести www.example.com/dashboard.php в браузере для прямого доступа к странице php.

Я все еще не понимаю, как .htaccess файлы фактически обрабатываются Apache.

Это поток, который выполняет код от начала до конца строка за строкой? Или что-то еще?

ОБНОВЛЕНИЕ

И это дает мне ERR_TOO_MANY_REDIRECTS ： 

RewriteEngine on

RewriteRule ^/?(.+)\.php$ /$1 [R=301]

RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]

Я кто-нибудь может объяснить, почему это приводит к слишком большому количеству перенаправлений

1 Ответ

0 голосов
/ 25 апреля 2020

Действительно, сервер apache http обрабатывает файлы конфигурации сверху вниз. Это также верно для распределенных файлов конфигурации (".htaccess"), , если они включены ...

Вы можете упростить свой подход: 

RewriteEngine on

RewriteRule \.php$ - [F,L]

RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_URI}.php [END]

A вариант, легче читаемый: 

RewriteEngine on

RewriteRule \.php$ - [F,L]

RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]

Примечание: разница между REQUEST_FILENAME и REQUEST_URI есть. Флаг QSA здесь не требуется, так как он используется по умолчанию. И L и END на самом деле не имеют смысла вместе (имейте в виду: END - это новый L ...).

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

RewriteEngine on

RewriteRule ^/?(.+)\.php$ /$1 [R=301]

RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]

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

В случае, если вы получаете внутреннюю ошибку сервера (http status 500), используя приведенное выше правило, есть вероятность, что вы используете очень старую версию apache http сервер. В этом случае вы увидите определенный намек на неподдерживаемый флаг [END] в файле журнала ошибок http-серверов. Вы можете попытаться обновить или использовать более старый флаг [L], он, вероятно, будет работать так же в этой ситуации, хотя это немного зависит от ваших настроек.

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

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

...