ПРОЕКТЫ 


  АРХИВ 


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 быстро наличие аутентификации проверять?



Такое я делал с помощью встроенного perl'а и наткнулся на криворукость 
программеров, которые в скриптах модифицировали URI и экранировали всё, что 
можно. Короче, судя по всему, сделали парсинг URI и выделение параметров своими 
кривыми руками уже из заэкранированного URI. Запрос клиента приходил в скрипт, 
скрипт экранил URI и делал редирект, т.е. запрос по редиректу приходил уже с 
экранированным URI.



В моём случае клиент, если приходил на бэкенд без ключа cookie или параметра в 
URI редиректился на получение такого ключа. Если клиент после редиректа получал 
ключ, то его пускало на бэкенд, если без ключа - то клиент ходил по редиректам 
(ну и боты вообще не редиректились).

При этом cookie позволяли добится только одного редиректа, а клиенты без куки 
каждый раз ходили получать значение key через редирект (т.е. GET-запрос без 
ключа - это три GET-запроса - 1-й - за оригинальным ресурсом, этот запрос 
редиректился, 2-й - за ключём, 3-й за оригинальным ресурсом, но уже с ключём 
авторизации).



На такую схему ушло 2 или 3 функции на встроенном перле, два локейшена и 3-4 
условия (if).





> что если попробовать модифицировать 

> http://wiki.codemongers.com/NginxHttpAccessKeyModule, чтобы он проверял не 

> GET-параметр, а куки, который и выставлять на бэкенде у авторизованных 
> пользователей



 




Copyright © Lexa Software, 1996-2009.