2015-04-30 1 views
5

mio php app rileva automaticamente che una richiesta di rotte per l'area di amministrazione tramite la parola chiave gestiscono nel cioè url:Nginx posizione del blocco di URL dinamico segmento

http://example.com/manage

Questa directory in realtà non esiste.

La richiesta deve essere instradata al file index.php che si trova sulla richiesta iniziale da gestire/ma qualsiasi collegamento produce un "Nessun file di input specificato". errore in nginx.

Ho bisogno di un blocco di posizione che funzioni su un segmento di URL inesistente.

ho cercato ri-scrittura per il file di indice principale in questo modo:

location /manage { 
    try_files $uri $uri/ @back; 
} 

location @back { 
    rewrite ^/manage/(.*)$ /index.php?_route_=$1 last; 
} 

che funziona bene per Apache ma in Nginx questo produce un errore 500.

Qualsiasi suggerimento sarebbe apprezzato.

UPDATE:

configurazione completa richiesto nei commenti:

upstream myapp { 
    server unix:/srv/users/serverpilot/run/myapp.php-fpm.sock; 
} 

server { 
    listen 80; 
    server_name my.domain.com; 

    root /srv/users/serverpilot/apps/myapp/public; 
    index index.php index.html index.htm; 

    access_log /srv/users/serverpilot/log/myapp/myapp_nginx.access.log; 
    error_log /srv/users/serverpilot/log/myapp/myapp_nginx.error.log; 

    location /asset { 
     rewrite ^/asset/(.*)$ /public/asset/$1 break; 
    } 

    location /image { 
     rewrite ^/image/(.*)$ /public/image/$1 break; 
    } 

    location/{ 
     try_files $uri $uri/ @front; 
    } 

    location @front { 
     rewrite ^/(.+)$ /index.php?_route_=$1 last; 
    } 

    location ~ \.php$ { 
     include fastcgi.conf; 
     fastcgi_pass myapp; 
    } 
} 

UPDATE: registro

Errore richiesto.

15/05/14 10:42:04 [error] 32704#0: 
*5 FastCGI sent in stderr: 
"Unable to open primary script: /srv/users/username/apps/myapp/public/manage/index.php (No such file or directory)" 
while reading response header from upstream, client: 129.349.569.789, 
server: myapp.example.com, 
request: "GET /manage/index.php?route=common/forgotten HTTP/1.1", 
upstream: "fastcgi://127.0.0.1:9002", 
host: "myapp.example.com", 
referrer: "http://myapp.example.com/manage" 

UPDATE:

richiesto .htaccess di file:

<IfModule mod_rewrite.c> 
    RewriteEngine On 
    RewriteRule ^(.*)/$ /$1 [L,R=301] 
    RewriteRule ^asset/(.*)$ public/asset/$1 [L,QSA] 
    RewriteRule ^image/(.*)$ public/image/$1 [L] 
    RewriteCond %{REQUEST_FILENAME} !-f 
    RewriteCond %{REQUEST_FILENAME} !-d 
    RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|txt|html|woff|ttf|eot|svg|css|js) 
    RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] 
</IfModule> 
+0

E dove portano questi collegamenti? –

+0

BTW, se sei sicuro che la directory 'manage' non esiste, puoi saltare' try_files' e mettere riscrittura direttamente nella prima posizione –

+0

Tutti gli URL con la parola chiave 'manage' route per i controller admin tramite index.php. E sì, sono sicuro che la directory non esiste. –

risposta

0

si è rivelato essere proprio sotto il naso per tutto il tempo.

upstream myapp { 
    server localhost:9002; 
} 

server { 
    listen 80; 
    server_name myapp.example.com; 

    root /srv/users/serverpilot/apps/myapp/public; 
    index index.html index.htm index.php; 

    access_log /srv/users/serverpilot/log/myapp/myapp_nginx.access.log; 
    error_log /srv/users/serverpilot/log/myapp/myapp_nginx.error.log; 

    location/{ 
     try_files $uri $uri/ @front; 
    } 

    location ~ ^/manage { 
     rewrite ^/(.+)$ /index.php?_route_=$1 last; 
    } 

    location ~ \.php$ { 
     include fastcgi.conf; 
     fastcgi_pass myapp; 
    } 

    location @front { 
     rewrite ^/(.+)$ /index.php?_route_=$1 last; 
    } 
} 

Grazie a @Dayo per tutto l'aiuto.

1

Dal registro degli errori e la configurazione che hai postato, la richiesta di /manage/index.php?route=common/forgotten corrisponderà sia le / e php posizione blocchi.

Dato come viene impostato Nginx Location Matching Order, il blocco di posizione PHP avrà sempre la precedenza e quindi la richiesta viene passata a FastCGI per l'elaborazione e poiché site.com/manage/index.php non esiste, si ottiene un errore. Cioè, il try_files in / e la riscrittura in @front non entrano mai nell'immagine.

Quello che dovete fare è aggiungere un blocco di posizione che ha una posizione più alta nell'ordine di localizzazione rispetto al blocco di posizione PHP per gestire tali richieste.

upstream myapp { 
    server unix:/srv/users/serverpilot/run/myapp.php-fpm.sock; 
} 

server { 
    listen 80; 
    server_name example.com; 

    root /srv/users/serverpilot/apps/myapp/public; 
    index index.php index.html index.htm; 

    access_log /srv/users/serverpilot/log/myapp/myapp_nginx.access.log; 
    error_log /srv/users/serverpilot/log/myapp/myapp_nginx.error.log; 

    location /asset { 
     rewrite ^/asset/(.*)$ /public/asset/$1 break; 
    } 

    location /image { 
     rewrite ^/image/(.*)$ /public/image/$1 break; 
    } 

    location/{ 
     try_files $uri $uri/ @front; 
    } 

    location ~ ^/manage { 
     rewrite ^([^?]*)$ /index.php?_route_=$1; 
    } 

    location ~ \.php$ { 
     include fastcgi.conf; 
     fastcgi_pass myapp; 
    } 

    location @front { 
     rewrite ^([^?]*)$ /index.php?_route_=$1; 
    } 
} 

Con questa disposizione, la richiesta verrà corrispondere i /, /Manage e php blocchi di localizzazione. /Manage e php essendo blocchi di tipi di espressioni regolari, avrà la precedenza e tra i due, /Manage, perché appare per primo, avrà la precedenza e il reindirizzamento di conseguenza.

Per il reindirizzamento, la richiesta corrisponderà ai blocchi di posizione / e php. php avrà la precedenza e come esiste site.com/index.php, elaborare di conseguenza.

PS. Ho notato che hai _route_ nella tua configurazione e route nel registro. Prendilo che è solo per test.

**** **** CONFIG ALTERNATIVA

upstream myapp { 
    server unix:/srv/users/serverpilot/run/myapp.php-fpm.sock; 
} 

server { 
    listen 80; 
    server_name example.com; 

    root /srv/users/serverpilot/apps/myapp/public; 
    index index.php index.html index.htm; 

    access_log /srv/users/serverpilot/log/myapp/myapp_nginx.access.log; 
    error_log /srv/users/serverpilot/log/myapp/myapp_nginx.error.log; 

    location ~ \.php$ { 
     include fastcgi.conf; 
     fastcgi_pass myapp; 
    } 

    location ~ ^/asset/(.*)$ { 
     rewrite^public/asset/$1; 
    } 

    location ~ ^/image/(.*)$ { 
     rewrite^public/image/$1; 
    } 

    location/{ 
     rewrite ^/(.+)/$ /$1 permanent; 
     try_files $uri $uri/ @front; 
    } 

    location @front { 
     rewrite ^/([^?]*)$ /index.php?_route_=$1; 
    } 
} 
+0

No, questo non funziona. Con entrambe le riscritture 'manage' abilitate, e con solo la seconda abilitata, l'url carica semplicemente la normale pagina indice. Se commento la seconda riscrittura 'gestisci' ottengo un 404. –

+0

L'intero URL per l'area di amministrazione deve rimanere intatto. L'area admin non usa alcuna riscrittura url in tutto tranne che nel segmento 'manage'. Quel segmento dice all'applicazione di caricare il modulo admin. Se quel segmento non è presente nell'URL, l'applicazione sa caricare il modulo frontale. –

+0

@VinceK Questo è effettivamente positivo in quanto significa che il blocco 'manage' sta gestendo le richieste ora e la riscrittura deve essere corretta. Avevo pensato che volevi modificare le richieste in arrivo del modulo, 'site.com/manage/ABC/XYZ'per' site.com/index.php? _route_ = ABC/XYZ', il che sembra non essere il caso. Quindi, puoi dare un esempio di richiesta/link in entrata e cosa si aspetta l'applicazione? Con queste informazioni, sarà banale modificare di conseguenza la regola di riscrittura. – Dayo