|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/371.32 27 Oct 2000 14:14:33
To : Pavel Kurnosoff
Subject : Re: Архитектура приложения ?
--------------------------------------------------------------------------------
<Pavel_Kurnosoff@p25.f736.n5030.z2.fidonet.org> wrote:
PK> 1. при использовании апачевской аутентификации можно сделать так, чтобы в
PK> качестве SID выступал UID, который можно получить из переменной
PK> $ENV{REMOTE_USER}.
PK> - если у нас не https, то мы гоняем логин/пароль по сети слишком часто и
PK> много.
PK> - при одновременном подключении нескольких юзеров с одним UID возможна
PK> фигня, т.к. они все будут работать с одной сессией и различить их
PK> _надежно_ никак нельзя.
PK> + легко реализуется
PK> 2. самый популярный метод - cookies. SID просто отдается/принимается в
PK> куке.
PK> - нет куков - нет и шоколадки :)
PK> + нет недостатков метода 1
PK> 3. второй по популярности метод - PATH_INFO. фишка в том, что если у нас в
PK> корне сервера лежит скрипт, скажем, session, то при всех запросах типа
PK> http://my.site.ru/session/some/fignya/34535.html мы получим запуск
PK> этого скрипта, причем в $ENV{PATH_INFO} будет лежать этот самый хвост
PK> /some/fignya/34525.html. как это использовать? а очень просто: после
PK> логина все наши url приобретают вид
PK> http://my.site.ru/session/<HАШ_SID>/some/where.html и все ссылки -
PK> только относительные. броузер-то думает, что у нас тут файлы-каталоги.
PK> соответсвенно для отдачи SID надо сделать _один_ _раз_ редирект на url
PK> с вставленным SID, а для чтения - просто брать его из PATH_INFO.
PK> - получаем жуткие url вида /session/23476547632547/some/where.html
PK> - возможены проблемы с тем, что до обычных файлов-то теперь не
PK> достучаться так, чтобы не потерять SID. т.е. все страницы, связанные
PK> с сессией должны отдаваться скриптом. как правило, они и так
PK> динамические, так что не страшно.
- SID светится в URL, т.е. подглядываем через плечо и оседаем в кешах,
логах, истории и т.п. Security.
PK> + может работать без куков, остальные плюсы наследуются ;)
PK> 4. вариация на тему 3. в dns прописываем маску так, что все запросы на
PK> *.my.site.ru отдаются вашему серверу. далее все то же самое, только
PK> редирект делаем на <HАШ_SID>.my.site.ru/some/where.html. достаем из
PK> HTTP_HOST.
PK> - url все-равно жуткие
PK> - надо лезть в настройки dns, а это не всегда можно
PK> + проблемы с файлами уже нет
Аналогично 3, SID светится.
PK> итак, imho ни один из методов имхо нельзя признать лучшим. так что всегда
PK> надо смотреть на задачу. в некоторых случаях можно/нужно дублировать
PK> методы - проверять, включены ли у юзера куки, и если да - использовать
PK> них. если нет - откатываться на метод 3 или 4. насколько я помню, так
PK> сделано на mail.ru.
Я пошел по другому пути - если есть куки, хорошо, если нет - вместо них
устроит Basic Authorization. Меня, правда, интересует идентификация юзера, а
не сессии, по крайней мере в том смысле, что двух одновременных сессий не
бывает (считаем одной сессией). Вообще же метод с куками, если их грамотно
генерировать (Wrapmod, глава 6) наиболее секьюрен в отсутствие SSL.
--
Счастливо!
Ран.
--- ifmail v.2.14.os-p7-tma3
* Origin: MemoNet (2:5020/371.32@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
