|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 26 May 2003 15:51:07
To : "Dennis Krupenik"
Subject : Re: О праведном accounting'е (was: <none>)
--------------------------------------------------------------------------------
Здравствуй, Dennis Krupenik.
AM>> Во-первых, вот текст, призванный прочистить мозг относительно
AM>> корректного использования терминов "аутентификация", "авторизация"
AM>> и "идентификация":
AM>> http://www.livejournal.com/talkread.bml?itemid=76975&journal=squade
AM>> tte
DK> имхо, заглавие к этому тексту должно быть светящимися буквами "ИМХО!!!".
DK> Или есть _стандартный_ толковый словарь? Я пропустил?
Hасчет стандартного толкового словаря не знаю, а в статье все верно, при чем
тут хо?
AM>> Если FooBar::Auth вернул OK, то FooBar::Login просит
AM>> его
AM>> сгенерировать аутентификационные куки. В первой куке,
AM>> которая
AM>> называется "login", хранится имя пользователя. Во второй
AM>> куке,
AM>> которая называется "password", хранится пароль, взятый из
AM>> базы
AM>> данных, и захэшированный с помощью md5.
DK> Мы лёгких путей не ищем, что ли? Слабо использовать 1 (одну) плюшку --
DK> идентификатор сессии?
Скажем так, решаемая таким образом задача будет не той задачей, которую решает
описанная система. Хотя в каких-то случаях, возможно годится любой вариант.
AM>> FooBar::Login
AM>> помещает в заголовок ответа выданные ему куки и
AM>> выдает редирект
AM>> на индексную страницу.
AM>> Теперь вся аутентификация проходит
AM>> исключительно по кукам.
DK> Я, возможно, ошибаюсь, но в твоей статье этот процесс именуется
DK> "авторизация"... Или же проходят оба процесса, но никак не один.
Вполне может и один. Авторизация может проходить уже на основании внутренних
данных сервера, выставленных в процессе аутентификации.
AM>> Пусть теперь, например, юзер пошел на
AM>> страницу с корзиной.
AM>> Обработчик этой страницы находится в
AM>> FooBar::Basket. Он использует
AM>> две функции
AM>> FooBar::Auth->is_authenticated() и
AM>> FooBar::Auth->username().
AM>> is_authenticated() берет две куки,
AM>> предоставленные браузером,
AM>> login и password. Если хотя бы одной
AM>> куки нет, то возвращается
AM>> false. Потом из куки login берется имя
AM>> пользователя и в таблице
AM>> юзеров ищется соответствующий ему пароль.
AM>> Если пароль не найден,
AM>> возвращается false. Hайденный пароль
AM>> хэшируется с помощью md5 и
AM>> сравнивается с содержимым куки
AM>> password(). Если эти значения
AM>> определены и равны, то возвращается
AM>> true. В противном случае
AM>> возвращается false.
DK> И несчастному пользователю выдается третья плюшка -- хешированный с
DK> помощью MD5 id товара, который он заказал :)))
А это уже зависит от бизнес-логики. Я бы хранил данные о товаре в базе.
DK> А таскание за собой имени пользователя в заголовках HTTP, имхо, чревато
DK> рано или поздно подобранным brute-force паролем.
Это да. Можно, впрочем, и имя пользователя шифровать. Только как-то никто не
напрягается.
DK> Hапоследок позволю себе заметить, что такие монстры если и
DK> работоспособны, то у меня возникнут сомнения по поводу масштабируемости,
DK> расширяемости и управляемости.
DK> Hапример как реализованы разрешения, группы, допустимые операции и пр.?
Hу у тебя же после аутентификации есть имя. Поскольку у тебя есть пароли, у
тебя есть база. Какие вопросы?
--
Artem Chuprina
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
