В корне сайта есть 3 папки
all — доступна всем
guest — доступно только не авторизированным
auth — доступна только авторизованным
Также в корне есть скрипт обработчик
index.php В нем такой код
В корне
Всё бы хорошо но не могу использовать $_GET
При переходе по ссылке mysite.ru/login/?key=1
Меня бросает на 404
Как исправить?
- Вопрос задан более двух лет назад
- 1416 просмотров
Ничего удивительного. Вы передаете переменную через ГЕТ key=1
Внутри PHP $_SERVER[‘REQUEST_URI’] = /login/?key=1
Далее по коду
Не думаю что у вас в auth/login/ найдется файл ?key=1.php
Не знаю с каких времён у вас такая дремучая конструкция. Такие городулины со времени похорон 4.3 не практиковал и не встречал.
Вердикт один — либо подбирайте другую переменную с корректным значением $page. Либо чистите эту. Убирая лишнее и анализируя подходит ли значение после фильтрации.
Человекопонятный URL (ЧПУ) — одна из самых часто затрагиваемых тем на различных форумах, посвящённых языку PHP. Можно до бесконечности спорить, нужны ли красивые URL-адреса для SEO-оптимизации, но факт того, что веб-сайт с ЧПУ выглядит аккуратно и профессионально отрицать глупо.
выглядит опрятно и интуитивно понятно для пользователя, нежели адрес вида
Кроме того, более-менее продвинутый пользователь в строке адреса броузера может стереть или заменить определенный путь иерархии в URL адресе, попав тем самым в нужное для него место на сайте (об этом хорошо написал Лебедев ещё в 2000 году — "Боремся за чистоту урлов", "Дублирующая навигация").
ЧПУ на базе модуля Apache mod_rewrite
Долгое вря ЧПУ делались с помощью небезызвестного модуля веб-сервера Apache mod_rewrite, который предназначен для манипуляции URL адресами. Директивы для mod_rewrite обычно писались разработчиками в .htaccess файле конфигурации Apache и выглядели примерно так:
Чем плох подобный механизм преобразований URL адресов, освоенный на mode_rewrite? Ничем не плох, но для разработки гибких веб-приложений он не подходит. В первую очередь потому, что преобразованием занимается сам mod_rewrite и система фактически завязана на файле конфигурации .htaccess. Мы не имеем возможности влиять на процесс преобразования, добавлять в автоматическом режиме новые виртуальные URL адреса, привязывать сложную логику к определённым виртуальным URL-адресам и делать многое другое.
ЧПУ на PHP
Конечно же, на одном PHP ЧПУ не сделать. Моудуль mode_rewrite как и раньше нужно использовать, но только лишь для того, что бы перенаправить все запросы к виртуальным ЧПУ-адресам в единую точку входа в приложении — в index.php. Для этого в .htaccess файле конфигурации можно прописать следующий код:
Данная запись означает буквально следующее: если запрошенный URL-адрес не является файлом, не является символической ссылкой и не является директорией, то подменить виртуальный адрес файлом index.php. При этом, суперглобальная переменная PHP $_SERVER[‘REQUEST_URI’] будет содержать именно запрошенный виртуальный адрес. Что это нам даёт? Фактически — безграничные возможности для манипулирования виртуальными адресами!
Пример № 1.
Во многих фреймворках ЧПУ строится по следующему принципу:
"Распарсить" такой URL и получить имя модуля, действие и параметры нет никаких проблем.
В данном случае под определением "модуль" и "действие" можно понимать что угодно:
Модуль — подключаемый файл, действие — функция или конструкция в блоке if-else
Модуль — класс, действие — метод класса
т.е. все зависит от вашей архитектуры приложения.
Далее по тексту "модуль" и "действие" будет также называться совокупным определением "обработчик".
Возьмем в пример такой URL-адрес:
и "распарсим" его с помощью нижестоящего кода, который поместим в единую точку входа — в index.php:
Вот так будет выглядеть результат для URL-адреса http://localhost/guestbook/edit_message/id/123:
Теперь, если у вас есть класс Guestbook, отвечающий за работу гостевой книги, то вы просто инстанцируете этот класс и вызываете его метод отвечающий за редактирование сообщения. Массив $params можно передать в метод в качестве аргумента метода:
view sourceprint?
1.
$guestbook = new $module();
2.
$guestbook->$action($params); // редактирование сообщения с > но лучше всего при подобном подходе поместить все полученные переменные из парсинга URL адреса в суперглобальный массив $_REQUEST:
Если же будет запрошен ошибочный URL -адрес:
то сработает исключение и в качестве обработчика будет фигурировать обработчик 404 ошибки:
Пример № 2.
Для понимания следующего подхода вам необходимы базовые знания Perl-совместимых регулярных выражений (POSIX).
Данный подход очень гибок и интересен, т.к. позволяет создавать практические любые виртуальные адреса, с абсолютно произвольной структурой и в отличие от предыдущего подхода — без упоминания в URL реального имени обработчика (модуля или действия). Суть метода заключается в следующем: каждый виртуальный URL-адрес, который может быть в системе, необходимо описать в виде регулярного выражения. Назначить для него обработчик. Если запрошенный URL совпадает с одним из таких регулярных выражений, то с помощью функций регулярных выражений нужно получить из URL необходимые данные, после чего передать их в обработчик. Пример:
Как видно из примера, так нужно будет описать все виртуальные URL адреса проекта. Напишем обработчик таких URL адресов:
Теперь при запросе
мы получим информацию о нужном нам обработчике (классе и методе класса), а так же массив параметров, с помощью которых и получим из СУБД информацию о теме в форуме:
Соответственно, инстанцирование нужного обработчика, т.е. класса Forum и запуск его метода viewTopick аналогичны запуску обработчика из примера №1.
В современных web-приложениях принято использовать концепцию единой точки входа. Эта концепция сводится к тому, что все запросы к серверу приложения переадресовываются на один файл, который, исходя из параметров запроса, координирует дальнейшее поведение скрипта. Такой подход дает огромные преимущества, как на этапе создания, так и на этапе поддержки проекта, так как кардинально уменьшается избыточность кода, а для приложений, манипулирующих динамическим контентом, единая точка входа — это единственное правильное решение.
Приведенные примеры актуальны для конфигурации web-сервера apache.
Концепция единой точки входа в реализации сводится к тому, что необходимо указать web-серверу перенаправлять все поступающие к нему запросы к файлу, который будет нашей единственной точкой входа, пусть к примеру это будет файл index.php в корневой директории приложения. Для этих целей у web-сервера Apache есть директива RewriteRule, находящаяся в модуле mod_rewrite. Синтаксис директивы следующий:
RewriteRule Шаблон Подстановка Флаги
Шаблон — это perl-совместимое регулярное выражение, которое применяется к текущему URL, причем под текущим подразумевается значение URL в момент применения этого правила. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что до этого момента возможно уже были применены другие правила к этому URL и соответственно преобразовали его.
Подстановка — это строка, которая будет заменять оригинальный URL, для которого есть совпадение Шаблону. Кроме текста в подстановке можно использовать много чего, но нас интересуют пока только лишь переменная сервера REQUEST_URI.
Из флагов воспользуемся лишь двумя — QSA и L. Первый указывает механизму преобразований на то, что нужно добавить, а не заменить, строку запроса из URL к существующей, в строке подстановки. Флаг L указывает серверу остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований.
Учитывая все выше сказанное, допишем в файл .htaccess в корневой директории приложения следующую строку:
Но не следует забывать о том, что кроме обращения непосредственно к скрипту, браузер будет запрашивать у сервера различные файлы ресурсов, такие как каскадные таблицы стилей, изображения, файлы со скриптами и т.п. Для того, чтобы сервер дал доступ браузеру к желаемому, нужно задать дополнительные условия директиве RewriteRule. Эти условия описываются директивой RewriteCond, которая определят когда следует делать преобразования в URL или когда необходимо оставить его без изменений.
Не вдаваясь глубоко в подробности, приведу несколько примеров, а более подробно об упомянутых директивах можно прочитать по ссылкам приведенным в конце статьи.
RewriteCond %
RewriteCond %
RewriteCond %
RewriteCond %
Смотря на приведенные строки, можно сразу заметить, что в них происходит сравнение REQUEST_URI со строкой, описанной perl-совместимым регулярным выражением, и в случае совпадения, подмены URL не происходит.
Примечание: Нужно не забывать о том, что все директивы RewriteCond должны быть описаны до использования RewriteRule.
Описанный выше способ — лишь один из возможных, рассмотрим как реализована концепция в Zend Framework.В предыдущем примере предполагалось, что точка входа находится в корневом каталоге веб-приложения, предлагаемая по умолчанию структура проекта на базе Zend Framework отличается тем, что каталог для общего доступа вынесен на уровень ниже, по умолчанию его имя public и доступ к веб-приложению настраивается таким образом, чтобы каталог public был корнем приложения, т.е. для получения доступа к ресурсам, находящимся вне директории public, в скрипте необходимо использовать условную адресацию для возврата на уровень выше либо же абсолютную адресацию, что вовсе не удобно, можно поступить например следующим образом:
Таким образом мы получили константу, содержащую относительный путь к логическому корню нашего приложения.
Осталось написать содержимое файла public/.htaccess:
RewriteCond %
RewriteCond %
RewriteCond %
RewriteRule ^.*$ — [NC,L]
RewriteRule ^.*$ index.php [NC,L]
Используя описанный подход, отпадает необходимость задавать определенные права доступа к публичным ресурсам приложения, теперь нам достаточно просто поместить их в директорию public и доступ к ним будет предоставлен автоматически, а доступ к файлам-скриптам приложения, находящимся вне public будет закрыт.
