GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самая актуальная информация Игорь Мазепа у нас.
Самые читаемые материалы
PHP: авторизация доступа(86236)
Как сделать Интернет-магазин?(67053)
Сессии в PHP(54968)
Веб-сайт: сборка по кирпичикам(31425)
СЕССИИ - обучение и /правильное/ использование(19988)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » PHP » PHP: авторизация доступа

PHP: авторизация доступа


Антон Орлов
orlov@professor.ru
http://antorlov.chat.ru

Страницы: [ 1 ] [ 2 ] [ 3 ]

Авторизация с помощью сессий

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

В связи с этим возникает вопрос: а нельзя ли как-нибудь избежать необходимости каждый раз осуществлять проверку логина и пароля посетителя? Чтобы, единожды авторизовав посетителя, впоследствии предоставлять ему доступ на страницы защищенной зоны без каких-либо проверок? Именно так, кстати, действует защита на основе средств web-сервера - файлов .htaccess, описанная в первом разделе главы. Но можно ли сделать то же самое средствами PHP? Да и вообще использовать cookie для хранения паролей не очень желательно: его содержимое может узнать любой, кто воспользуется компьютером, на котором этот cookie сохранен (многие браузеры хранят cookie в предназначенной для них папке, даже если "время жизни" cookie истекло и он больше не принимается сервером).

Напрашивается первое предложение: а почему бы, например, после успешной авторизации не отправить посетителю cookie с какой-либо пометкой (например, устанавливать в 1 значение переменной в этом cookie), а впоследствии проверять не наличие записанных в cookie логина и пароля в файле паролей или базе данных, а присутствие в cookie этой самой пометки, одинаковой для всех, прошедших авторизацию? Или даже сделать разные типы пометок и в зависимости от типа предоставлять посетителю разные возможности на сайте?

Сделать-то так можно, да вот устойчивость такой системы авторизации к взлому будет не особо великой. Злоумышленнику будет достаточно узнать, что за пометку помещает сценарий авторизации в cookie, чтобы получить к защищенной зоне полный доступ - просто вручную создав такой cookie. (А если при проверке "пометки" использовался не элемент массива $HTTP_COOKIE_VARS, а одноименная переменная, то и просто подставив ее значение в адресной строке при заходе на страницу с такой проверкой: например, page.php?auth=1.) Кроме того, просмотреть значение cookie на компьютере посетителя и узнать, какие его имя и значение являются "пометкой", тоже не так трудно.

Но самое главное - посетители нередко отключают использование cookie при своих путешествиях по Интернету. При отключенных cookie описанная выше система авторизации на их основе работать не будет.

Как же быть?

Следует использовать весьма интересный механизм сессий, появившийся в 4-й версии PHP.

Сессии

"Сессия" - несколько абстрактное понятие, означающее нечто вроде "законченного периода работы с сайтом". Например, в сессию могут входить такие действия, как "приход на сайт - загрузка данных - уход с сайта". Иногда определения сессии разнятся в своей формулировке, но суть примерно такая.

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

Иными словами - работа механизма сессий в PHP происходит так. Когда посетитель заходит на сайт и для него устанавливаются какие-либо переменные (сам ли он их вводит или, скажем, они берутся из базы данных), то команды начала и регистрации сессии сохраняют эти переменные в определенном месте на самом сервере (в специальном файле в папке временных файлов сервера, рис.8.7, 8,8).

Файлы с данными сессий в папке временных файлов сервера. Имена файлов соответствуют идентификаторам сессий.
Рис.8.7. Файлы с данными сессий в папке временных файлов сервера. Имена файлов соответствуют идентификаторам сессий.

Cодержимое одного из таких файлов. В сессии сохранены переменные: legus, wq1, wq2, wq3.
Рис.8.8. Содержимое одного из таких файлов. В сессии сохранены переменные: legus, wq1, wq2, wq3.

Если у посетителя браузер принимает cookie, то ему высылается cookie (с определенным именем - по умолчанию "PHPSESSID"), содержащий так называемый "идентификатор сессии" (рис.8.9), а если нет, то web-сервер автоматически помещает данный идентификатор в переменную PHPSESSID в каждую ссылку (рис.8.10) на выдаваемых посетителю страницах сайта (естественно, "внутреннюю" - то есть ведущую на другие страницы того же самого сайта, с тем же самым доменным именем). Таким образом, идентификатор передается на сервер при каждом заходе посетителя на какую-либо из страниц сайта. При этом идентификатор выбирается либо из соответствующего cookie, установленного посетителю при открытии сессии, либо из адресной строки ссылки, куда этот идентификатор автоматически помещается web-сервером.

Содержимое сookie с идентификатором сессии.
Рис.8.9. Содержимое сookie с идентификатором сессии.

Ссылка с идентификатором сессии.
Рис.8.10. Ссылка с идентификатором сессии.

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

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

Бесспорно, набор сохраненных переменных, относящихся к одной сессии, будет существовать на сервере не вечно. В параметрах файла конфигурации PHP - php.ini - указывается, какое время жизни устанавливается для cookie с идентификатором сессии (по умолчанию 0 - то есть до закрытия окна браузера и всех открытых из него окон), а также через какое время данные сессий из папки временных файлов удаляются физически (рис.8.11). Кроме того, существует специальная команда "разрушения сессии", которая при своем выполнении уничтожает сохраненные в папке временных файлов данные сессии и тем самым делает недействительным идентификатор сессии. Параметры устанавливаемых cookie, в частности, их "время жизни" также можно задать специальной командой в сценарии на PHP, однако время хранения данных сессии в папке временных файлов определяется параметром в php.ini, так что при использовании виртуального хостинга вам не всегда удастся настроить работу с сессиями полностью так, как вам бы хотелось.

Файл php.ini, раздел настроек параметров сессий.
Рис.8.11. Файл php.ini, раздел настроек параметров сессий.

Чтобы использовать в сценарии на странице возможности работы с сессиями, необходимо включить в него команду session_start()3 , - как при первоначальной установке переменных, так и при последующей работе с ними4. Чтобы указать, какие переменные следует сохранять в качестве данных сессии, следует использовать команду session_register("имя первой переменной", "имя второй переменной",... и т.д.), а чтобы закрыть сессию - команду session_destroy(). При закрытии сессии переменные, переданные сценарию с ее помощью, не обнуляются (последнее делает команда session_unset();), так что их можно использовать и в остальной части сценария.

Переменные сессии доступны на сценариях сайта по своим изначальным именам - скажем, если командой session_register переменная $a была зарегистрирована в качестве сессионной, то ее значение будет доступно под тем же самым именем - $a - на всех страницах сайта, где используются сессии (т.е. в их начале размещена команда session_start()).

Однако в целях безопасности лучше работать в сценарии с переменными сессии через автоматически создаваемые массивы $HTTP_SESSION_VARS и (в PHP версий 4.1 и старше) $_SESSION, используя одноименные с переменными элементы этих массивов. Дело в том, что в этом случае сценарий будет огражден от возможных попыток злоумышленников передать ему значения этих переменных через указание их в адресной строке, если сессия не была открыта (в указанные массивы попадают те и только те данные, что были получены с сессией). Такая передача может привести, скажем, к тому, что переменная - пометка об успешном прохождении авторизации будет получена сценарием не из данных сессии (в которых она может появиться только после успешного ввода посетителем правильных логина и пароля), а от злоумышленника.

Сценарий авторизации

Алгоритм сценария прост. После определения допустимости полученных от посетителя каким бы то ни было образом (вводом в форму или в диалоговое окно авторизации) логина и пароля открывается сессия и в ней регистрируется переменная - указатель на успешную авторизацию, которой присваивается определенное значение. На каждой странице "защищенной зоны" проверяется значение полученной с данными сессии этой переменной (а, как вы помните, берется оно не из отправляемых браузером посетителя данных, а из созданного во временной директории сервера файла с данными сессии - браузер посетителя сообщает лишь идентификатор этого файла), и если оно совпадает с обозначающим успешную авторизацию, то посетитель допускается к работе со страницей, если же нет - то доступ к странице не разрешается. На странице "выхода" из защищенной зоны располагается команда session_destroy();, после выполнения которой идентификатор сессии "забывается" сервером и передача сценарию переменной - указателя на успешную авторизацию более не происходит - до нового прохождения авторизации.

Начало сценария на странице проверки логина с паролем может быть таким:

	<?php
	foreach (file("passw/passwr") as $k)
	{if (substr($k, 0, -2)=="$PHP_AUTH_USER $PHP_AUTH_PW")
	{$rez=1;}}
	if($rez!=1)
	{Header("WWW-Authenticate: Basic realm=\"Защищенная зона"\""); Header("HTTP/1.0 401 Unauthorized"); 
	...текст страницы, выдающейся посетителю в случае нажатия им кнопки "Отмена"...
	exit;}

или таким (если логин и пароль передаются из формы в переменных $login и $pass):

	<?php
	foreach (file("passw/passwr") as $k)
	{if (substr($k, 0, -2)=="$login $pass"){$rez=1;   }}
	if($rez!=1)
	{...текст страницы, выдающейся посетителю в случае ввода неправильных логина и пароля...
	exit;}

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

Продолжение же сценария довольно простое. Создаем сессию...

	session_start();

...регистрируем переменную:

	session_register("auth");

...и устанавливаем ей определенное значение - дабы потом его и проверять.

	$auth=1;

Собственно, и все.

	?>

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

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

На каждой странице "защищенной зоны", в самом ее начале нужно поставить код

	<?php
	session_start();
	if ($auth!=1)
	{...текст страницы, выдающейся посетителю в случае попытки несанкционированного досту-па...
	exit;}

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

Страница выхода из "защищенной зоны" должна содержать код5

	<?php
	session_start();
	session_destroy();
	?>

После его выполнения для посещения страниц "защищенной зоны" вновь потребуется авторизация.

Если посетитель не воспользовался страницей выхода из защищенной зоны, то время, в течение которого из его браузера можно попасть на другие ее страницы, определяется настройками в файле php.ini. По умолчанию cookie с идентификатором сессии, устанавливаемым данному посетителю, существует до закрытия всех окон браузера, а сами данные сессии хранятся несколько часов. Существует команда session_set_cookie_params() (подробную информацию о ней смотрите в Описании PHP), с помощью которой можно установить другое "время жизни" cookie, однако для изменения настроек в файле php.ini необходимо иметь права администратора для web-сервера.

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

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

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

[3] - Так как при работе с сессиями используются cookie, то данная команда должна находиться в начале страницы, перед какими-либо выводимыми в браузер данными.
[4] - Если в файле php.ini установлен в 1 параметр session.auto_start, то это делать не обязательно.
[5] - Если в файле php.ini установлен в 1 параметр session.auto_start, то указывать команду session_start() на каждой странице, где исполь-зуются переменные сессии или производятся действия с самой сессией, не обязательно.

 
21.08.2003
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.