Nginx, auth e forçando HTTPS - como um snippet de inclusão?

Question

Ficou um pouco preso aqui. Eu gostaria de um bom e simples Nginx "incluir" snippet capaz que requer HTTP AUTH para o local que está incluído, e força um redirecionamento para HTTPS, se ainda não estiver.

Eu inventei isso:

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

e usou-o assim (exemplo bobo para a brevidade, o mundo real, temos django servindo / e / estático / como um atalho de arquivos de recursos):

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

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

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

Funciona muito bem para qualquer coisa manipulada por localização /

wget -S mostra que está primeiro emitindo um redirecionamento 301 para a mesma URL, mas com o protocolo https. Então ele volta com um 401 corretamente.

O problema é para URLs em / static

A autenticação é ativada pela herança de diretivas.

Mas parece que o "if ($ https!=" on ") ..." não está sendo herdado no bloco de localização aninhado.

Então, um wget -S vai diretamente para o 401, convidando o usuário a efetuar login usando uma conexão insegura, o que obviamente é uma Coisa Ruim.

Eu posso ver porque o "if" está tendo problemas (o try_files também não herda).

Mas isso me deixa um pouco preso.

Alguma alma gentil pode sugerir uma abordagem mais limpa? A única regra é (idealmente) que eu gostaria que o AUTH fosse requerido em um ou mais locais por uma simples linha "include" para evitar erros.

E a herança seria boa - novamente para evitar erros. Claro, podemos executar esse "include" em todos os blocos de localização e isso funciona. Mas se guardarmos "/" seria bom saber que protegemos todo o site e um desenvolvedor inocentemente adicionando outro bloco de localização não pode de repente abrir um buraco de segurança.

Muito obrigado,

Tim

    

Answer 1

Comandos como if , try_files , proxy_pass e uwsgi_pass não são herdados por blocos de localização aninhados. Outras configurações como auth_ldap são herdadas.

link

Não consigo encontrar nenhuma documentação oficial sobre quais tipos de sintaxe de configuração são "comandos" e quais são os itens de configuração regulares. O comportamento de herança para locais aninhados parece estar indocumentado.

Abordagem mais limpa

Não use locais aninhados porque o comportamento da herança é indocumentado e ninguém se sentirá confiante em fazer alterações no futuro. Simplesmente repita-se, mas repita-se com inclusões. Talvez você possa criar outra inclusão do "standard-behavior.conf" e colocar coisas como try_files lá.

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;
}

    

Answer 2

301 Redirecionamentos podem forçar seu site TODO INÍCIO a usar https, se isso for o caso, então você não deve veicular nada, exceto redirecionamentos 301 pela porta 80,

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

Lembre-se que TUDO tem que ser HTTPS se você usar essa diretiva 301, e cada subdomínio terá que ser HTTPS também - não é uma coisa ruim. Verifique também se server_name está definido antes de usá-lo na definição do site - não vi isso em seu exemplo configs.