LINUX.ORG.RU

[Perl][Сессии] Алгоритм авторизации.


0

0

Такс, уважаемые, в данный момент пытаюсь разобраться с таким понятием, как Сессии [в общем случае]. Что я понял: при обращении к какому-либо скрипту (напр. script.cgi) он ищет $sid, переданный клиентом, в значениях которые хранится на сервере (файл/БД - пох), если нашел - все хорошо и продолжаем работу дальше, если не нашел - редиректим на другой скрипт (напр. login.cgi), который принимает логин+пароль и, если они валидны (способ проверки опустим), - создает сессию и редиректит на script.cgi, который уже может оперирует такими вещами, как login (напр. для доступа к БД). Тут возникает несколько вопросов общего характера:

  • Правильно ли я понял смысл сессий?
  • Существуют ли иные способы реализовать подобное, (названий/определений для поиска инфы хватит)?

Собственно примеры есть, но хотелось бы лучше понять этот механизм.
Спасибо.

Например, так

В dbPager Server (http://www.dbpager.com) понятие пользовательской сессии применяется для ассоциации какого-либо набора переменных (например, признака авторизации) с конкретным пользователем. Поскольку web по своей природе асинхронен, идентификатор сессии необходимо передавать в каждом обращении пользователя к серверу. Реализованы пользовательские сессии с помощью механизма cookies. После того, как создается переменная в пользовательском контексте, сервер сохраняет эту переменную в памяти или передает её значение для хранения в memcached (в зависимости от заданного в конфиигурации механизма), после чего передает браузеру сессионный cookie вида session=уникальный идентификатор. Контекст пользователя (набор переменных, связанных с ним) ассоциируется с этим уникальным идентификатором. Сессионные cookie хранятся в браузере пользователя до его закрытия. При осуществлении следующего запроса к серверу, браузер передает значение cookie серверу. Сервер по переданному значению находит сохраненную ранее переменную и оперирует с её значением. В dbPager Server этот механизм хранения привязанных к конкретному пользователю переменных прозрачен для разработчика.

Таким образом, процедура авторизации может выглядеть следующим образом:

клиент -> (переходит на страницу авторизации) -> сервер

сервер -> (загрузка страницы авторизации) -> клиент

клиент -> (отправка данных формы авторизации) -> сервер (проверка имени пользователя и пароля, сохранение признака авторизации в памяти)

сервер -> (генерация уникального идентификатора сессии и его ассоциация с признаком авторизации, передача клиенту идентификатора в сессионном cookie и начальной страницы, либо страницы с сообщением об ошибке) -> клиент

клиент -> (переход на другую страницу, отправка идентификатора сессии посредством cookie) -> сервер

сервер -> (проверка наличия признака авторизации по переданному идентификатору сессии, передача затребованной страницы либо страницы с сообщением об ошибке авторизации) -> клиент

dennis_pro ()

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

simple_best_world_web_master ()
Ответ на: комментарий от simple_best_world_web_master

Да, так лучше всего не делать, хотя для простых случаев самое оно - сессии есть и клиент сам с ними долбится

simple_best_world_web_master ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.