☰

Regex Nginx para obter uri menos localização

tag-icon • tag-icon nginx regex
Regex Nginx para obter uri menos localização

Tenho o Nginx rodando como proxy reverso para alguns aplicativos. Uma diretiva de localização está sendo executada corretamente, enviando solicitações para um arquivo de soquete unix e posteriormente para seu aplicativo wsgi upstream. A diretiva com a qual estou tendo problemas élocation ~ ^/sub/alarm(.*)$. Tenho algumas reescritas que parecem estar funcionando, mas caso elas entrem em conflito com minhas outras intenções, explicarei minha intenção com cada diretiva:

  • A primeira diretiva do servidor deve redirecionar todos os http para https. Isso parece funcionar bem.
  • A segunda diretiva de servidor possui uma diretiva de localização que direciona o tráfego para meu aplicativo wsgi. Isso funciona bem. A outra diretiva de localizaçãoEu pretendia usar para servir conteúdo estático /home/myuser/alarm.example.com/quando um GET é recebido paraexample.net/sub/alarm. (por exemplo, example.net/sub/alarm/pretty.css deve entregar /home/myuser/alarm.example.com/pretty.css) Em vez disso, o aplicativo wsgi é carregado.
  • A última diretiva do servidor deve redirecionar alarm.example.net para example.net/sub/alarm, pois não tenho um certificado curinga, mas desejo um atalho e criptografia fáceis. Isso parece funcionar bem.

conf:

server {
    listen 80;
    listen [::]:80 ipv6only=on;
    server_name example.com www.example.com;
    rewrite ^/(.*) https://example.com/$1 permanent;
}

server {
        listen 443 ssl;
        listen [::]:443 ipv6only=on ssl;
        charset utf-8;
        client_max_body_size 75M;
        server_name example.com www.example.com;
        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        location / {
                include uwsgi_params;
                uwsgi_pass unix:///tmp/example.com.sock;
        }

        location ~ ^/sub/alarm(.*)$ {
                alias /home/appusername/alarm.example.com;
                index index.html;
                try_files $1 $1/;
        }
}

server {
        listen 80;
        server_name alarm.example.com;
        rewrite ^ $scheme://example.com/sub/alarm$request_uri permanent;
}

eu olheicomo remover o bloco de localização de $uri na configuração do nginx?para tentar obter a parte do meu arquivo de localização após o uri. Acho que estou faltando alguma coisa sobre prioridades.

Outra tentativaestava sem regex:

location /sub/alarm/ {
        alias /home/appusername/alarm.example.com;
        index index.html;
        try_files $uri $uri/index.html =404;
}

No caso acima, consegui carregar index.html ao acessar alarm.example.com (que redirecionou corretamente parahttps://example.com/sub/alarm/), mas todos os recursos estavam gerando um 404.

Finalmente tentei combinar as duas tentativas, mas parece que não consigo colocar o til dentro do bloco de localização ('diretiva desconhecida' ao recarregar o Nginx):

location /sub/alarm/ {
        ~ ^/sub/alarm(.)$
        try_files /home/appusername/alarm.example.com$1 /home/appusername/alarm.example.com$1/;
}

Notas Adicionais

  • O aplicativo dinâmico em example.com não tem nenhuma relação com o aplicativo de "alarme", que é estático. Ele está incluído apenas porque está sendo veiculado em vez do aplicativo de alarme quando tento usar o regex.
  • Sempre evitei aprender qualquer coisa sobre regex (provavelmente imprudente, mas nunca precisei disso nos últimos 7 anos até hoje) e estou pagando o preço agora que estou configurando o Nginx. eu useiRegex 101para obter minha string regex de ^\/sub\/alarm(.*)$. Parecia indicar que eu precisava usar barras de escape, mas o Nginx não parece mostrar isso nos exemplos. Por favor, deixe-me saber se há outro conceito que preciso estudar. Eu encerro oficialmente minha postura de evitar regex a partir de hoje.
  • Se a sintaxe fosse válida o suficiente para o Nginx recarregar, meu erro ocorreu 2015/10/12 20:25:57 [notice] 30500#0: signal process startedem todas as tentativas.

Responder1

Então o usuário (eh... eu) perdeu algo que deveria ser uma pista evidente:

No caso acima, consegui carregar index.html ao acessar alarm.example.com (que redirecionou corretamente para https://example.com/sub/alarm/), mas todos os recursos estavam gerando um 404.

Mesmo que esse exemplo ainda não estivesse correto, eudeveria ter verificado as permissões de arquivo nos arquivos de recursos. O Nginx está sendo executado como www-data e no grupo do arquivo index.html, mas precisava estar no grupo para todos os arquivos. O proprietário do arquivo é o usuário appusername.

Desde então, adicionei outro aplicativo (chamado 'cerveja') que é roteado como alarme. Agora aprendi o básico do regex e consegui fazer isso em um bloco de localização:

server {
    listen 80;
    listen [::]:80 ipv6only=on;
    server_name example.com www.example.com;
    rewrite ^/(.*) https://example.com/$1 permanent;
}

server {
        listen 443 ssl;
        listen [::]:443 ipv6only=on ssl;
        charset utf-8;
        client_max_body_size 75M;
        server_name example.com www.example.com;
        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;
        error_log /var/log/nginx/error.log warn;

        location ~ ^/sub/(alarm|beer)(.*)$ {
                alias /home/appusername/$1.example.com/;
                #index  index.html index.htm;
                try_files $2 $2/ =404;
        }

        location / {
                include uwsgi_params;
                uwsgi_pass unix:///tmp/example.com.sock;
        }
}

server {
        listen 80;
        server_name alarm.example.com;
        rewrite ^ $scheme://example.com/sub/alarm$request_uri permanent;
}

Não se importe com a mudança para os blocos de localização. Isso é apenas coincidência de digitar e redigitar.

informação relacionada