Nginx служит Django в подкаталоге через uWSGI

Question

Я уже пережил несколько предыдущих потоков: 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

Основной урок заключается в том, что вы должны только настроить свой сайт (ы доступный) для достижения это. Теперь я пробовал различные перестановки из

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

Все отлично работает, когда я определяю место, чтобы быть «/» (и удалить SCRIPT_NAME, модификатор1, PATH_INFO и корень не имеет значения. Но пытаться использовать подкаталог всегда приводит к Страница не найдена (404).?

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

(редактировать) это ДОБАВЛЕНИЕ каталог на запрос Что я не выясняя

(пробовал forced_script_name - should't должны использовать это и дает другие типы головных болей - и настройка конфигурации uwsgi)

EDIT:

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

Не работает ... Гнездо там и работает, когда я устанавливаю для/- я просто не могу видеть, что я пропускаю.

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

Это загружает сайт, но все ссылки указывают на http://example.com/link/to/something вместо http://example.com/project/link/to/something

Answer 1

В конце концов отказался от попыток сделать это «аккуратно».

Окончательное решение состояло только в том, чтобы внести переменную параметров, которую я префикс в static_url и проект urls.py. Нет SCRIPT_NAME или ничего сложного на стороне nginx.

Answer 2

Прежде всего, удалите uwsgi_modifier1 30;. Django будет обрабатывать SCRIPT_NAME сам по себе и не должен иметь PATH_INFO, переписанный uWSGI. Это может быть вредно, если SCRIPT_NAME не удаляется из заголовков uWSGI.

Во-вторых, удалите uwsgi_param PATH_INFO "$1"; из конфигурации nginx. PATH_INFO уже определен в файле uwsgi_params, и он должен быть $document_uri (как есть в uwsgi_params), а не $1, если вы проходите SCRIPT_NAME в django.

После этих настроек django должен обрабатывать SCRIPT_NAME в качестве префикса URL-адреса и будет корректировать диспетчер URL-адресов и URL-адрес, обратный этому.

Answer 3

Если приложение настолько простое, что простой «префикс» можно добавить в одну строку в urls.py, тогда я предпочитаю это простое решение без каких-либо дополнительных действий.

В противном случае «/ префикс» должен быть добавляется к domain столбца в записи для вашего сайта в сайтов таблицы в Django администратора. Домен должен быть затем «example.com/project» со вторым решением, поскольку Django должен знать домен и префикс, особенно для правильной перенаправления. Естественно, префикс должен быть также удален из URL-адреса запроса веб-сервером, как вы делаете это сейчас в настройках nginx.

Я обычно расколоть проверку таких внедрений на два вопроса:

• ли сообщать веб-сервер (Nginx) ожидаемые более короткие или более длинные URL-адреса в Django?
• Знает Django свой полный базовый URL-адрес и использует ли он его во всех веб-страницах?

Я использую как журнал регистрации nginx, так и регистрацию в Django, чтобы увидеть, какие из них в конечном итоге неправильно настроены. (Вы не написали достаточно важной информации.)

Важным случаем, который следует протестировать, является: Убедитесь, что веб-страницы, требующие аутентификации, перенаправляются на страницу входа правильно и обратно, даже если вы пытаетесь использовать эти URL после выхода из системы.

Более подробную информацию можно найти в similar question.

Answer 4

nginx uwsgi_modifier1 устарел в uWSGI.

Ваша цель состоит в том, чтобы иметь возможность размещать приложение wsgi из любого места без приложения, которое необходимо настроить для учета того, где он обслуживается.

В настоящее время метод для этого в uWSGI является карта точек монтирования для каждой комбинации приложения URI, как так:

[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 может занять место module

Для Джанго специально ,

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