ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Как на nginx быстро нали чие аутентификации провер ять?



Мы с Вами несколько с разных сторон смотрим, Ваш случай только ддос, я же говорю о авторизации на уровне бекенда.

Куку неплохо бы проверить на валидность, при условии конечно что она есть, например если бекенд контролирует время жизни или не активности сессии, я думаю не очень хорошаяя идея контролировать это на стороне фронтенда, не общий случай. Кроме того, если держать как информацию "колбаса"+customer ip, это отсеит отснифанные запросы с "чужими" куками. Формирование куки я бы доверил бекенду. Задача фронтенда проверить что кука есть, что она валидная (есть в кеше и с "правильного" адреса) и если все так то передать бекенду. Бекенд в этом случае может быть уверен что если ему что то пришло, то эта сессия есть, живая и правильная.

На счет не поддерживающих куки - у меня реализовано как может быть кука с "колбасой", может быть параметр сервлета вида сессия=колбаса.

Alex Vorona wrote:
Kostya Alexandrov пишет:
Это близкие задачи, зачем разделять,
задачи близкие, только хитов в эти задачи ожидается разное количество в контексте ддоса.
 nginx хороший фронтенд, если просто
сможет обращаться за кукой в  "хранилище" то уже здорово(!)
зачем ему обращаться за кукой куда-то? Куку он видит(или не видит, если её нет) в запросе клиента. Если кука есть, nginx зная ключ и видя ИП, с которого пришёл запрос, генерит хэш и сравнивает его с кукой.. По результатам сравнения запрос клиента отрабатывает или клиент получает 40x. Нет куки - выдавать мелкий хтмл с текстом "введите в строке браузера" и картинку с url, либо js/html-редирект, либо 40x, либо ... :)
А то что у меня снизилась нагрузка на бекенде разве это плохо? можно считать его тяжелым :)

Если еще привязать куку к бекенду в апстриме, то вааще будет очень круто. Это фактически раскидывание сессий по нодам на которых прошла авторизация. По ip так можно делать, но это несколько не то.

да, как вариант, такое возможно. Только и о неподдерживающих куки клиентах в этом случае надо как-то подумать
Alex Vorona wrote:
Kostya Alexandrov пишет:
Совершенно верно, согласно профайлеру (потратил часа два) отключение проверки авторизации снижает нагрузку с 22-23 до 18-19 %
с камней
речь идёт о бэкенде? Я предлагаю использовать модуль nginx как фильтр неавторизованных запросов ботов на тяжёлые части сайта(к которым должны обращаться только авторизованые клиенты), а не как акселератор проверки авторизации для тех, у кого она есть.
плюс уходит время которое тратится на доступ к синхронизированным контейнерам сессий и т.п, но кроме самой куки надо еще помнить с какого ip она может быть (откуда была авторизация)

IP сидит в самой куке хэшем вместе с ключём.
Alex Vorona wrote:
Kostya Alexandrov пишет:
Помоему разными локейшенами разруливается легко.

Alex Vorona wrote:
alekciy пишет:
даже в расчищенной квоте есть "Неавторизованные пользователи имеют доступ только к паре статических страничек и скрипту логина." Если вопрос в другом - сформулируйте его, возможно я не так понял сабж.
Насколько я понял, основной вопрос это "Как грамотно реализовать
быструю
проверку _внутри_ nginx, что пользователь действительно прошел
авторизацию и имеет активную сессию?"
...и видимо как потом максимально эффективно уведомить бэкэнд за
nginx-ом
о том, что пользователь действительно авторизован?
а для чего? Неавторизованные пользователи не пропускаются nginx'ом
никуда кроме формы логина. Бэкенд после авторизации выставляет куки,
который является пропуском для остальных страниц на уровне nginx.


в тех локейшнах, которые ждут только авторизованных пользователей и
проксируются на бэкенд, надо nginx'ом быстро проверять авторизацию.















 




Copyright © Lexa Software, 1996-2009.