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

[Deomid Ryabkov <myself@xxxxxxxxxxx>]

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

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

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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