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

Сб Янв 16 23:23:12 MSK 2010

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