Re: Асинхронная авторизация

[Deomid Ryabkov]

Vladimir Romanov wrote:
> Кука выдается сразу пользователю чтобы понять когда он придет повторно
> с того-же устройства. Один и тот-же пользователь может приходить с
> разных компьютеров и различать их просто по имени пользователя не
> получится.
>   
а зачем? к вам приходит юзер без валидной авторизационной куки,
но с логином и паролем. какая вам разница, с какого он устройства?
вы идёте в аутентификатор, проверяете юзер/пароль и либо выдаёте ему
кук и редирект, либо отправляете далеко. при этом надо различать
состояния "лдап перегружен, приходи позже" и "лдап сказал, что пароль 
неправильный".
ну тут уж как удобнее, на второй случай можно предусмотреть 403,
а на первый давать отлупы 401.

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

> Не хочется отсылать LDAP запрос из NGINX, т.к. он может выполняться не
> быстро и это оприведет к задержкам в обработке других запросов. Также
> есть идея, что если лимита хватает то проверять ранее выданные куки. А
> это уж точно надо делать отдельным процессом.
> LDAPов у меня несколько и надо еще понимать в какой из них лезть (по
> IP) и лимит считать отдельно для каждого. Еще периодически надо
> пречитывать таблицу с LDAPами и обновлять внутренние структуры.
>
> 2010/1/16 Deomid Ryabkov <myself at rojer.pp.ru>:
>   
>> Vladimir Romanov wrote:
>>     
>>> Добрый день!
>>>
>>> Работаю я тут над одним проектом.  И етсь там задача авторизации
>>> пользователей, причем достаточно хитрая. Пользователи могут приходить
>>> из разных регионов. В каждом регионе свой LDAP. При этом есть
>>> ограничение - нельза слать больше чем N запросов в секнуду на каждый
>>> LDAP. В качестве клиента будет выступать приложение на компьютере
>>> пользователя. Как я хочу сделать сейчас.. При запроме пользователя
>>> выдавать ему куку
>>>       
>> зачем?
>>     
>>>  и возвращать ему 401, а информацию заносить в базу.
>>>
>>>       
>> опять же - зачем?
>>     
>>> Отдельный процесс будет выбирать записи из базы, и посылать запросы в
>>> нужный LDAP c указанной скоростью. При последующих запросах
>>> пользователя уже можно будет пропустить.
>>> Есть ли более правильные способы?
>>>
>>>       
>> имхо, просто сделать авторизационный процесс, который делает авторизацию
>> с нужным рейт-лимитом, а всё что свыше лимита - посылает нафиг.
>> куку пользователю выдавать только после успешной авторизации,
>> в результате со временем все пользователи будут окучены (то есть обзаведутся
>> куками :)
>> и перестанут трогать лдап. щастье наступает при условии что пропускной
>> способности лдапа
>> таки хватает на окучивание пользователей/реавторизацию (если для кук
>> предусмотрено ограниченное время жизни).
>> держать очередь запросов, считаю, совершенно нет нужды - пусть клиенты
>> проявляют настойчивость,
>> тем более что они, как я понял, железные, а не сидят и не тычут в кнопку
>> "login".
>>
>> --
>> Deomid "rojer" Ryabkov
>> myself at rojer.pp.ru
>> rojer at sysadmins.ru
>> ICQ: 8025844
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>     
>
>
>
>   


-- 
Deomid "rojer" Ryabkov
myself at rojer.pp.ru
rojer at sysadmins.ru
ICQ: 8025844

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3308 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100116/a256221a/attachment-0001.bin>