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

[Vladimir Romanov <vromanov@xxxxxxxxx>]

У меня все сложнее. Используется не пароль и имя пользователя.. а 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
>
>



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