nginx servire Django in una sottodirectory attraverso uWSGI

Question

ho già passato attraverso alcuni discussioni precedenti: How do I set subdirectory in nginx with Django how to deploy django under a suburl behind nginx Serving flask app on subdirectory nginx + uwsgi

La lezione di base è che si dovrebbe solo bisogno di configurare il sito (s-disponibili) per ottenere Questo. Ho provato varie permutazioni di

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

location = /favicon.ico { access_log off; log_not_found off; } 
location /static/ { 
    root /path/to/project; 
} 

location /project/ { 
    root   /path/to/project; 
    include   /etc/nginx/uwsgi_params; 
    uwsgi_param  SCRIPT_NAME /project; 
    uwsgi_modifier1 30; 
    uwsgi_param PATH_INFO "$1"; 
    uwsgi_pass  unix:/tmp/project.sock; 
}} 

Tutto funziona perfettamente quando mi definisco posizione di essere "/" (e rimuovere SCRIPT_NAME, modifier1, PATH_INFO e la radice non ha importanza. Ma cercando di utilizzare una sottodirectory risultati sempre pagina non trovata (404):.?

Request URL: http://www.example.com/project/project 

(edit) e 'l'aggiunta di una directory alla richiesta di cosa sto non capire

(forced_script_name provato - should't necessario utilizzare questo e dà altri tipi di mal di testa e impostazioni di configurazione uwsgi)

EDIT:

location /project/ { 
    root   /path/to/project; 
    include   /etc/nginx/uwsgi_params; 
    uwsgi_param  SCRIPT_NAME /project; 
    uwsgi_pass  unix:/tmp/project.sock; 
} 

non funziona ... La presa c'è e funziona quando ho configurato per/- non riesco proprio a vedere che cosa mi manca.

UPDATE:

location ~ /project(?<path_info>/.*|$) { 
    include   /etc/nginx/uwsgi_params; 
    uwsgi_pass  unix:/tmp/project.sock; 
    uwsgi_param  PATH_INFO $path_info; 
    uwsgi_param  SCRIPT_NAME /project; 
} 

Questo carica il sito, ma tutti i link puntano a http://example.com/link/to/something invece di http://example.com/project/link/to/something

Answer 1

Alla fine ha rinunciato a provare a fare questo "ordinatamente".

La soluzione finale era solo per creare una variabile di impostazioni che ho aggiunto come prefisso al file static_url e ai progetti urls.py. Nessun SCRIPT_NAME o qualcosa di complicato sul lato nginx.

Answer 2

Prima di tutto, rimuovere uwsgi_modifier1 30;. Django gestirà da solo SCRIPT_NAME e non è necessario che lo PATH_INFO venga riscritto da uWSGI. Può essere dannoso se SCRIPT_NAME non viene rimosso dalle intestazioni da uWSGI.

In secondo luogo, rimuovere uwsgi_param PATH_INFO "$1"; da nginx config. PATH_INFO è già definito nel file uwsgi_params e dovrebbe essere $document_uri (come in uwsgi_params), non $1 se stai passando a django SCRIPT_NAME.

Dopo questi ritocchi, Django dovrebbe trattare SCRIPT_NAME come prefisso URL e regolerà l'invio di url dispatcher e url a quello.

Answer 3

Se l'applicazione è così semplice che un semplice "/ prefisso" può essere aggiunto a una riga in urls.py, preferisco questa semplice soluzione senza altro.

caso contrario, il "/ prefisso" deve essere allegato alla colonna domain nel record per il sito in Siti tavolo in Django admin. Il dominio dovrebbe essere quindi "example.com/project" con la seconda soluzione, perché Django deve conoscere il dominio e il prefisso, in particolare per il reindirizzamento corretto. Naturalmente il prefisso deve essere anche rimosso dall'URL della richiesta dal server web, come lo si fa ora nelle impostazioni di nginx.

Io di solito dividere la verifica di tali implementazioni a due domande:

• Vuol segnalare il web server (nginx) le attese URL più o meno lunghi a Django?
• Conosce Django come URL completo di base e lo usa in tutte le pagine Web in modo coerente?

Io uso sia il registro nginx che il logging Django abilitato per vedere quale di essi è eventualmente configurato in modo errato. (Non hai scritto abbastanza informazioni importanti.)

Un caso importante che deve essere testato è: Verificare che le pagine Web che richiedono l'autenticazione vengano reindirizzate correttamente alla pagina di accesso, anche se si provano questi URL dopo il logout.

Maggiori dettagli possono essere trovati nel similar question.

Answer 4

Il nginx uwsgi_modifier1 è obsoleto in uWSGI.

Il tuo obiettivo è essere in grado di ospitare un'app wsgi da qualsiasi luogo senza che l'app debba essere regolata per tenere conto di dove viene servita.

L'attuale metodo per fare questo in uWSGI è quello di mappare punti di mount per ogni combinazione app URI in questo modo:

[uwsgi] 
socket = 127.0.0.1:3031 
; mount apps 
mount = /app1=app1.py 
mount = /app2=app2.py 
; rewrite SCRIPT_NAME and PATH_INFO accordingly 
manage-script-name = true 

Hosting multiple apps in the same process (aka managing SCRIPT_NAME and PATH_INFO)

mount può prendere il posto di module

per Django specificamente ,

; Before 
module = django_app.wsgi:application 
; After 
mount = /django_app=django_app.wsgi:application 
manage-script-name = true