Django und ALLOWED_HOSTS

Django, Flask, Bottle, WSGI, CGI…
Antworten
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

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?
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Lass dir die variable einfach per print ausgeben, ob wie auch wirklich gesetzt ist...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

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…
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

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.
Antworten