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

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

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


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

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru