Форумы админов пестрят сообщениями о повышении «безопасности» путем отключения «лишних» http-запросов. Под горячую руку народ не разобравшись что только не ставит. Так что наткнуться можно и не на такое…
Когда я работал в университете что-то подобное было и у нас. В роли «неумолимого карателя» правда выступал дешевый ламинат, коим был застелен пол компьютерного класса. В зависимости от стечения обстоятельств (влажности, свитера или кроссовок студента и т.п.) длинна искры от накопленного статического заряда, проскакивающей между usb-портом и флешкой, могла достигать пары мм!
Компьютеров с живыми USB не было ни одного.
А когда ПК сменили на новые, USB-порты заранее заклеили изолентой. Во избежание.
Спасибо! Пост исправлен. If'ов в конф. файле больше нет.
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Однако, как подсказали в комментариях и я только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Попробую объяснить более абстрактно. Предположим, у нас есть веб-сервер Apache (или группа веб серверов), что обслуживает, опять же предположим, домашние странички пользователей: /~username1 и /~username2. Перед ним установлен Nginx. У обоих (в общем случае N) пользователей установлена популярная CMS cmsname. У username1 в корне, у username2 в подкаталоге /superblog/. За авторизацию пусть отвечает login.php.
Конфигурацией вида location ~* /login.php мы с легкостью поймаем обе формы авторизации. Ваш же пример /location login.php — не сработает ни у одного из пользователей.
Если заменить в статье "/wp-login.php" на "/user/login", то защищать будем Drupal. Если на "/administrator/" — то Joomla. Можно ещё 10 разных CMS привести. Wordress для примера взят, как самый популярный.
В примере с Nginx можно защитить любую подстроку, не зная наперед в корне или подкаталоге она располагается. Этим конфигурационным файлом не только wordpress закрыть можно.
И да, наверное стоило в конфигурационном примере для haproxy сделать так же, воспользовавшись path_sub вместо path_beg.
А антистатик мы на свои покупали — не помогал практически.
Компьютеров с живыми USB не было ни одного.
А когда ПК сменили на новые, USB-порты заранее заклеили изолентой. Во избежание.
Если вдруг сохранился в резервных копиях старый стенд, посмотрю, что была за ошибка.
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
Я упустил момент, в котором nginx начал позволять использовать proxy_pass в location ~*. Однако, как подсказали в комментариях и я только что проверил на тестовом стенде, 1.6.2 спокойно это переваривает. Люблю сообщество как раз за такие вещи!
На одной из более ранних версий nginx оно не срабатывало. Вот, правда, не помню на чем именно — на proxy_pass или на limit_req
Дополню-ка пост:)
Попробую объяснить более абстрактно. Предположим, у нас есть веб-сервер Apache (или группа веб серверов), что обслуживает, опять же предположим, домашние странички пользователей: /~username1 и /~username2. Перед ним установлен Nginx. У обоих (в общем случае N) пользователей установлена популярная CMS cmsname. У username1 в корне, у username2 в подкаталоге /superblog/. За авторизацию пусть отвечает login.php.
Конфигурацией вида location ~* /login.php мы с легкостью поймаем обе формы авторизации. Ваш же пример /location login.php — не сработает ни у одного из пользователей.
И да, наверное стоило в конфигурационном примере для haproxy сделать так же, воспользовавшись path_sub вместо path_beg.
Функциональное программирование в шелле на примере xargs: habrahabr.ru/post/153785/
trac.nginx.org/nginx/ticket/650
Так же очень важно, чтобы одновременно с send-proxy на HAProxy был включен proxy_protocol на Nginx.