Это близкие задачи, зачем разделять, nginx хороший фронтенд, если просто
сможет обращаться за кукой в "хранилище" то уже здорово(!)
А то что у меня снизилась нагрузка на бекенде разве это плохо? можно
считать его тяжелым :)
Если еще привязать куку к бекенду в апстриме, то вааще будет очень
круто. Это фактически раскидывание сессий по нодам на которых прошла
авторизация. По 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'ом быстро проверять авторизацию.
