Мы с Вами несколько с разных сторон смотрим, Ваш случай только ддос, я
же говорю о авторизации на уровне бекенда.
Куку неплохо бы проверить на валидность, при условии конечно что она
есть, например если бекенд контролирует время жизни или
не активности сессии, я думаю не очень хорошаяя идея контролировать это
на стороне фронтенда, не общий случай. Кроме того, если
держать как информацию "колбаса"+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'ом быстро проверять авторизацию.
