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

Vladimir Romanov vromanov на gmail.com
Вс Янв 17 09:05:47 MSK 2010


> ничем принипиально не отличается от проверки юзера/пароля.
> не забудьте выдать пользователю куку, чтоб в следующий раз
> не нужно было ходить в медленный лдап.
Это конечно! Это уже сделано. Сделал как модуль авторизации nginx.
Сейчас почти готов прототип отдельного процесаа который шлет запросы к
LDAP (на С)
>>
>> нагрузка будет весьма велика. Вешать авторизацию на бакенд нельзя.  В
>> случе чего, он сдохнет под нагрузкой.
>>
>
> в том и смысл, что нагрузка на авторизацию будет ровно такая, какую вы
> скажете.
На авторизацию да. Но надо будет сначал принять решение авторизовать
или сразу послать. А для принятия такого решения надо как минимуму
делать селект в базе. Что при большом количестве "неокученых"
пользователей приведет к большой загрузке.

> авторизатор принимает бытрое рещение - можно ещё запрос отправить лдапу или
> нет.
> если можно - отправляет, проверяет, даёт куку. нельзя - даёт отлуп юзеру,
> чтоб пришёл попозже.
Вот принятие этого решения тоже дорогая операция и выносить в бакенд,
например на php не хочется.
>>
>>  Есть еще один момент - это
>> кластеризация. Саму вебчасть можно спокойно кластеризовать используя
>> репликацию DB. А вот релизовтаь ограничения по количесву обращений к
>> LDAP в таком кластере  будет сложнее.
>
> надо сказать, что лдап тоже умеет реплицироваться. может вам не парить мозг,
> а просто обеспечить требуемую нагрузочную способность лдапа с помощью
> репликации?
Этот LDAP не может :(. Со временем будет другой интерфейс.
>>
>>  Эту часть лучше оформить в виде
>> active/stand bay пары
> тут я не понял.
т.е. два сервера. Один работает, второй проверяет рабоает ли первый.
Как только первый останавливается за заботу принимается первый.

-- 
Vladimir Romanov


Подробная информация о списке рассылки nginx-ru