Назад | Перейти на главную страницу

Nginx, auth и принудительное использование HTTPS - как включаемый фрагмент?

Здесь немного застрял. Я бы хотел иметь хороший простой Nginx, способный «включить» фрагмент, который требует HTTP AUTH для местоположения, в которое он включен, И принудительно перенаправляет на HTTPS, если еще не сделал этого.

Я придумал это:

# /etc/nginx/snippets/requirelogin-staff.conf
if ($https != "on") {
    return 301 https://$server_name$request_uri;
}
auth_ldap "Login Required";
auth_ldap_servers staff;

и использовал его так (глупый пример для краткости, в реальном мире у нас есть django, обслуживающий / и / static / в качестве ярлыка файлов ресурсов):

location / {
    include snippets/requirelogin-staff.conf;

    try_files $uri $uri/index.html $uri.html =404;

    location /static {
        alias /var/www/webroot/liv/static;
    }
}

Он отлично подходит для всего, что связано с местоположением /

wget -S показывает, что сначала выполняется перенаправление 301 на тот же URL, но с протоколом https. Затем он возвращается с ошибкой 401.

Проблема связана с URL-адресами в / static

Auth запускается путем наследования директив.

Но похоже, что "if ($ https! =" On ") ..." не наследуется во вложенный блок местоположения.

Таким образом, wget -S направляется непосредственно к 401, предлагая пользователю войти в систему, используя небезопасное соединение, что, конечно же, является плохой вещью.

Я могу понять, почему с «if» возникают проблемы (try_files тоже не наследует).

Но это оставляет меня в тупике.

Может ли какая-нибудь добрая душа предложить более чистый подход? Одно правило (в идеале) состоит в том, что я бы хотел, чтобы AUTH требовался в одном или нескольких местах с помощью аккуратной единственной строки «включить», чтобы избежать ошибок.

И наследование было бы неплохо - опять же, чтобы не ошибиться. Конечно, мы можем запустить это «include» для каждого блока местоположения, и это действительно работает. Но если мы охраняем «/», было бы неплохо знать, что мы охраняли весь сайт, и разработчик, невинно добавивший еще один блок местоположения, не может внезапно пробить брешь в безопасности.

Большое спасибо,

Тим

Команды вроде if, try_files, proxy_pass, и uwsgi_pass не наследуются вложенными блоками расположения. Другие настройки, такие как auth_ldap передаются по наследству.

https://stackoverflow.com/a/32126596

Я не могу найти никакой официальной документации о том, какие типы синтаксиса конфигурации являются «командами», а какие - обычными элементами конфигурации. Поведение наследования для вложенных расположений кажется недокументированным.

Более чистый подход

Не используйте вложенные местоположения, потому что поведение наследования недокументировано, и никто не будет уверен, что вносит изменения в будущем. Просто повторите, но повторите с включением. Возможно, вы могли бы создать еще одно включение "standard-behavior.conf" и поместить туда такие вещи, как try_files.

location /static {
    include snippets/requirelogin-staff.conf;
    try_files $uri $uri/index.html $uri.html =404;

    alias /var/www/webroot/liv/static;
}

location / {
    include snippets/requirelogin-staff.conf;
    try_files $uri $uri/index.html $uri.html =404;
}

301 редирект может заставить ваш ВЕСЬ сайт использовать https, если это предназначено, тогда вы не должны обслуживать ничего, кроме 301 редиректа через порт 80,

{ # Http Redirect
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name _;
   return 301 https://$server_name$request_uri;
}

Просто помните, что ВСЕ должно быть HTTPS, если вы используете эту директиву 301, и каждый субдомен также должен быть HTTPS - неплохая вещь. Также дважды проверьте, что название сервера определяется до того, как вы используете его в определении сайта - я не видел этого в ваших конфигурациях примеров.