Seite 1 von 1
Django und ALLOWED_HOSTS
Verfasst: Montag 17. August 2015, 19:08
von kbr
Möglicherweise habe ich Tomaten auf den Augen, denn ich finde es auch per Google nicht:
An einem kleinen Projekt teste ich gerade die Migration auf Python 3.4 mit Django 1.8.3.
Klappt alles prima, aber nach dem Deployment gibt's Ärger mit den Settings:
Code: Alles auswählen
class Production(Common):
DEBUG = False
ALLOWED_HOSTS = ['*']
Setze ich auf dem Server DEBUG auf True, so läuft alles einwandfrei. Bei False aber erhalte ich einen BAD REQUEST (400) Error, und zwar auch dann, wenn ALLOWED_HOSTS auf die nicht empfehlenswerte Wildcard gesetzt ist. Ist das bekannt und übersehe ich etwas?
Re: Django und ALLOWED_HOSTS
Verfasst: Montag 17. August 2015, 21:16
von jens
Lass dir die variable einfach per print ausgeben, ob wie auch wirklich gesetzt ist...
Re: Django und ALLOWED_HOSTS
Verfasst: Dienstag 18. August 2015, 07:19
von apollo13
In Django stehen settings im Normalfall in einer Datei auf Modulebene, du arbeitest hier offensichtlich mit Klassen, deswegen solltest du auch die entsprechenden Pakete etc angeben und in einer shell schauen ob am Ende alles in django.conf.settings steht…
Re: Django und ALLOWED_HOSTS
Verfasst: Dienstag 18. August 2015, 11:39
von kbr
apollo13 hat geschrieben:In Django stehen settings im Normalfall in einer Datei auf Modulebene, du arbeitest hier offensichtlich mit Klassen, deswegen solltest du auch die entsprechenden Pakete etc angeben und in einer shell schauen ob am Ende alles in django.conf.settings steht…
Ja, das stimmt natürlich. Ich nutze django-configurations (master-branch wg. Django 1.8 ). Ein Test heute ergab, dass die django.conf.settings korrekt sind.
Inzwischen habe ich auch die Lösung gefunden. Der Fehler war ganz doof: Django läuft mit Gunicorn hinter Nginx. Auf die Schnelle hatte ich übersehen, im proxy-header $http_host einzufügen. Dies fällt nicht unbedingt auf, da Django dann den Servernamen als host verwendet. Dieser wird von Nginx als Upstreamname des verwendeten Sockets übertragen. Dieser aber enthielt im konkreten Fall ein Zeichen, dass nicht dem regulären Ausdruck der host_validation entsprach und Django somit host und ports jeweils auf leere Strings setzte. Das hat dann eine SuspiciousOperation-Exception ausgelöst.