☰

Nginx regex para obtener uri menos ubicación

tag-icon • tag-icon nginx regex
Nginx regex para obtener uri menos ubicación

Tengo Nginx ejecutándose como proxy inverso para un par de aplicaciones. Una directiva de ubicación se ejecuta correctamente y envía solicitudes a un archivo de socket Unix y luego a su aplicación wsgi ascendente. La directiva con la que tengo problemas eslocation ~ ^/sub/alarm(.*)$. Tengo un par de reescrituras que parecen estar funcionando, pero en caso de que choquen con mis otras intenciones, explicaré mi intención con cada directiva:

  • La primera directiva del servidor debería redirigir todos los http a https. Esto parece que funciona bien.
  • La segunda directiva del servidor tiene una directiva de ubicación que dirige el tráfico a mi aplicación wsgi. Esto funciona bien. La otra directiva de ubicaciónQuise usarlo para servir contenido estático desde /home/myuser/alarm.example.com/que se recibe un GET paraexample.net/sub/alarm. (por ejemplo, example.net/sub/alarm/pretty.css debería entregar /home/myuser/alarm.example.com/pretty.css) En su lugar, se carga la aplicación wsgi.
  • La última directiva del servidor debería redirigir alarm.example.net a example.net/sub/alarm ya que no tengo un certificado comodín pero quería un acceso directo y cifrado fáciles. Esto parece que funciona bien.

configuración:

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

Miré¿Cómo eliminar el bloque de ubicación de $uri en la configuración de nginx?para intentar obtener la parte de mi archivo de ubicación después del uri. Creo que me estoy perdiendo algo sobre las prioridades.

Otro intentoestaba sin expresiones regulares:

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

En el caso anterior pude cargar index.html cuando iba a alarm.example.com (que redirigió correctamente ahttps://ejemplo.com/sub/alarm/), pero todos los recursos arrojaban un 404.

Finalmente intenté combinar ambos intentos, pero parece que no puedo poner la tilde dentro del bloque de ubicación ('directiva desconocida' al recargar Nginx):

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

Notas adicionales

  • La aplicación dinámica en example.com no tiene ninguna relación con la aplicación de "alarma", que es estática. Se incluye solo porque se muestra en lugar de la aplicación de alarma cuando intento la expresión regular.
  • Siempre he evitado aprender algo sobre expresiones regulares (probablemente imprudente, pero nunca lo necesité en los últimos 7 años hasta hoy) y estoy pagando el precio ahora que estoy configurando Nginx. solíaexpresión regular 101para obtener mi cadena de expresiones regulares de ^\/sub\/alarm(.*)$. Parecía indicar que necesitaba usar barras de escape, pero Nginx no parece mostrarlo en los ejemplos. Por favor, avíseme si hay otro concepto que necesito estudiar. Termino oficialmente mi postura de evitar expresiones regulares a partir de hoy.
  • Si la sintaxis era lo suficientemente válida para que Nginx se recargara, mi error estuvo 2015/10/12 20:25:57 [notice] 30500#0: signal process starteden todos los intentos.

Respuesta1

Entonces el usuario (eh... yo) se perdió algo que debería haber sido una pista evidente:

En el caso anterior pude cargar index.html cuando iba a alarm.example.com (que redirigió correctamente a https://ejemplo.com/sub/alarm/), pero todos los recursos arrojaban un 404.

Aunque ese ejemplo todavía no era correcto,debería haber verificado los permisos de archivo en los archivos de recursos. Nginx se ejecuta como www-data y en el grupo del archivo index.html, pero necesitaba estar en el grupo de todos los archivos. El propietario del archivo es el usuario appusername.

Desde entonces, agregué otra aplicación (llamada 'cerveza') que se enruta como una alarma. Ahora aprendí los conceptos básicos de expresiones regulares y pude hacer esto en un bloque de ubicación:

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

No te preocupes por cambiar el orden de los bloques de ubicación. Esa es sólo una coincidencia de escribir y reescribir.

información relacionada