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

[Deomid Ryabkov <myself@xxxxxxxxxxx>]

Vladimir Romanov wrote:
> У меня все сложнее. Используется не пароль и имя пользователя.. а MAC
> и IP.
это те же яйца, только в профиль.
>  Программа смотрит MAC устройства. Шлет запрос указывая этот мак.
> Сервер обращается к оборудованию и рповеряет, действительно ли этому
> IP (от кого пришел запрос) соответствует этому маку? Если
> соответствует - считаем что пользователь указал правильный мак и
> выадем пользователю информацию связанную с этим маком. например,
> баланс.
>   
ничем принипиально не отличается от проверки юзера/пароля.
не забудьте выдать пользователю куку, чтоб в следующий раз
не нужно было ходить в медленный лдап.
> нагрузка будет весьма велика. Вешать авторизацию на бакенд нельзя.  В
> случе чего, он сдохнет под нагрузкой.
>   
в том и смысл, что нагрузка на авторизацию будет ровно такая, какую вы 
скажете.
авторизатор принимает бытрое рещение - можно ещё запрос отправить лдапу 
или нет.
если можно - отправляет, проверяет, даёт куку. нельзя - даёт отлуп 
юзеру, чтоб пришёл попозже.
>  Есть еще один момент - это
> кластеризация. Саму вебчасть можно спокойно кластеризовать используя
> репликацию DB. А вот релизовтаь ограничения по количесву обращений к
> LDAP в таком кластере  будет сложнее.
надо сказать, что лдап тоже умеет реплицироваться. может вам не парить мозг,
а просто обеспечить требуемую нагрузочную способность лдапа с помощью 
репликации?
>  Эту часть лучше оформить в виде
> active/stand bay пары
>   
тут я не понял.
> 2010/1/16 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
> >
> >
> > _______________________________________________
> > 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