Das Setzen von DEBUG = False verursacht 500 Fehler

298

Sobald ich das ändern DEBUG = False, wird meine Website generieren 500 (mit wsgi & manage.py runserver), und es gibt keine Fehlerinformationen in Apache error log und es wird normal laufen , wenn ich ändern debugzu True.

Ich verwende Django 1.5 & Python 2.7.3. Hier ist das Apache-Zugriffsprotokoll und ohne Protokoll im Apache-Fehlerprotokoll

www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET / HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22"
www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET /favicon.ico HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22"
www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET /favicon.ico HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22"

Hier ist meine Einstellungsdatei:

import os.path    
DEBUG = False 
#TEMPLATE_DEBUG = DEBUG

HERE = os.path.dirname(__file__)
ADMINS = (
    ('admin', '[email protected]'),
)

MANAGERS = ADMINS

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'zdm',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': 'passwd',                  # Not used with sqlite3.
        'HOST': '',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'America/Chicago'

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'

SITE_ID = 1

# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = True

# If you set this to False, Django will not use timezone-aware datetimes.
USE_TZ = True

# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = ''

# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = ''

# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
#STATIC_ROOT = os.path.join(HERE, 'static').replace('\\','/')

# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'
#STATIC_ROOT = os.path.join(HERE, 'static').replace('\\','/')
S= os.path.join(HERE, 'static').replace('\\','/')

# Additional locations of static files
STATICFILES_DIRS = (
    # Put strings here, like "/home/html/static" or "C:/www/django/static".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    '/home/zdm/static',
)

# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
#    'django.contrib.staticfiles.finders.DefaultStorageFinder',
)

# Make this unique, and don't share it with anybody.
SECRET_KEY = '9a7!^gp8ojyk-^^d@*whuw!0rml+r+uaie4ur$(do9zz_6!hy0'

# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.Loader',
    'django.template.loaders.app_directories.Loader',
#     'django.template.loaders.eggs.Loader',
)

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # Uncomment the next line for simple clickjacking protection:
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

ROOT_URLCONF = 'zdm.urls'

# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'zdm.wsgi.application'

TEMPLATE_DIRS = (
    # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    '/home/zdm/templates',
)

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
    'zdm',
    'portal',
    'admin',
    'tagging',
)
zhiguo.wang
quelle
Ja, ich habe 403 & 404 500 HTML-Datei in meinen Vorlagen dir
zhiguo.wang
Haben Sie 500.html- und 404.html- und 403.html-Dateien? Ich erinnere mich an ein Problem mit einem bereitgestellten Projekt, bei dem diese Dateien nicht im Stammverzeichnis meines Vorlagenverzeichnisses gespeichert waren.
esse
Wenn Ihre Site einen 500-Fehler generiert, sollte das Apache-Protokoll einige Informationen enthalten. Möglicherweise möchten Sie einen Teil des Endes der Fehlerprotokolldatei einfügen, damit die Benutzer sie anzeigen können.
esse
87
Vielleicht möchten Sie Ihr SECRET_KEY jetzt ändern, da es öffentlich verfügbar ist ...
Fraxtil
1
Dies ist nicht die Antwort für alle. Wie unten unter stackoverflow.com/a/37218484/4028977 gezeigt , kann dies viele Gründe haben. Mit einer einfachen Protokollierung können Sie dies ohne Rätselraten herausfinden.
Rob

Antworten:

413

Django 1.5 hat die Einstellung für zulässige Hosts eingeführt , die aus Sicherheitsgründen erforderlich ist. Eine mit Django 1.5 erstellte Einstellungsdatei enthält diesen neuen Abschnitt, den Sie hinzufügen müssen:

# Hosts/domain names that are valid for this site; required if DEBUG is False
# See https://docs.djangoproject.com/en/1.9/ref/settings/#allowed-hosts
ALLOWED_HOSTS = []

Fügen Sie Ihren Host hier wie ['www.beta800.net']oder ['*']für einen schnellen Test hinzu, aber verwenden Sie ihn nicht ['*']für die Produktion .

Ric
quelle
32
Wow - das hat uns hart gebissen. Es ist wirklich schade, dass diese Einstellung in den Dokumenten vergraben ist. Unsere Produktionsstätte würde mit DEBUG = False nicht funktionieren. Vielen Dank für den Hinweis !!!
Shreddd
4
Weitere Informationen zu den Sicherheitsproblemen, die diese Einstellung eingeführt haben: Praktische HTTP-Host-Header-Angriffe . Wird Sie definitiv davon überzeugen, nicht ['*']in der Produktion zu verwenden.
Gertvdijk
4
bl. ärgerlich, dass sie es nicht einmal als Standardwert in settings.py einfügen, vielleicht mit einem ausführenden Kommentar ...
hwjp
7
Manchmal frage ich mich, warum Django immer zurückgebliebener wird! Sicherlich sind diese Leute viel bessere Programmierer als ich, aber ich verstehe die Entscheidung, Schwachstellen auf Anwendungsebene zu "beheben", nicht wirklich, wenn der eigentliche und saubere Schritt darin besteht, den Server richtig zu konfigurieren. Gleiches gilt für "Vorlagen-Caching" und "dauerhafte Verbindungen" ... Nutzloser Code, der auf einer seriösen Website niemals verwendet wird; wird immer noch als der heilige Gral der Programmierung dargestellt! Vielleicht bin nur ich, ich habe mich vorher geirrt!
StefanNch
3
Vergiss das Problem. Es hing mit dem django-pipelineVerhalten zusammen, wenn die statische Aufladung noch nicht erfasst wurde. Als allgemeiner Tipp handle_uncaught_exceptionhilft Ihnen das Platzieren eines Haltepunkts in Djangos Methode dabei, herauszufinden, was hier vor sich geht.
Pieter
51

Ich weiß, dass dies spät ist, aber ich habe hier nach meinem Fehler 500 gesucht. DEBUG=FalseIn meinem Fall stellte sich heraus, dass dies der Fehler war , ALLOWED_HOSTSaber ich habe ihn os.environ.get('variable')zum Auffüllen der Hosts verwendet. Ich habe dies erst bemerkt, als ich die Protokollierung aktiviert habe Protokollieren Sie alle Fehler in der Datei mit der folgenden und es wird protokolliert, auch wenn DEBUG=False:

# settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
            'datefmt' : "%d/%b/%Y %H:%M:%S"
        },
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
    },
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': 'mysite.log',
            'formatter': 'verbose'
        },
    },
    'loggers': {
        'django': {
            'handlers':['file'],
            'propagate': True,
            'level':'DEBUG',
        },
        'MYAPP': {
            'handlers': ['file'],
            'level': 'DEBUG',
        },
    }
}
squareborg
quelle
16
Dies sollte die akzeptierte Antwort sein. Es ist viel nützlicher, einfach das Framework selbst zu fragen, was nach Verwendung der Produktionseinstellungen falsch ist, anstatt zu raten.
Stefan Dragnev
4
In der Tat ist dies nichts, worüber man im Dunkeln herumwandern kann. Schauen Sie sich einfach die Fehlermeldung an, die Sie normalerweise mit dieser Methode sehen würden. In meinem Fall fehlte mir eine andere Einstellung in meiner settings.py, nach der meine App suchte. Alles was ich brauchte war das Protokoll, um dies aufzuspüren. Ein wichtiger Hinweis: Ich habe / path / zu / my / django / vor dem 'mysite.log' hinzugefügt, wie im Beispiel für Dokumente gezeigt: docs.djangoproject.com/de/1.10/topics/logging/#examples
Rob
4
Ich habe stundenlang nach einer Lösung gesucht, die keinen Sinn hat. Laut dieser Antwort verwenden Sie einfach die Protokollierung und Sie sollten Ihr Problem haben, dies ist die beste Antwort. Danke OP!
Stapel
Meine Serverfehler scheinen keine Protokolle zu erzeugen! Ich habe verschiedene Protokollierungskonfigurationen ohne Erfolg ausprobiert. Irgendwelche Ideen?
Cammil
5
Danke dir! Dies löste meinen Fehler. Es stellte sich heraus, dass ich collectstatic ausführen musste, um einige statische Assets aus einem Paket zu sammeln.
Themessup
33

Ich habe das gleiche Problem erst kürzlich in Django 2.0 festgestellt. Ich konnte das Problem durch Einstellen herausfinden DEBUG_PROPAGATE_EXCEPTIONS = True. Siehe hier: https://docs.djangoproject.com/de/2.0/ref/settings/#debug-propagate-exceptions

In meinem Fall war der Fehler ValueError: Missing staticfiles manifest entry for 'admin/css/base.css'. Ich habe das behoben, indem ich lokal ausgeführt habe python manage.py collectstatic.

Kyle Gibson
quelle
Ich gehe das gleiche, aber collectstatic hat es nicht für mich behoben. Haben Sie den Fehler "Kann nicht erreicht werden" erhalten? Wie haben Sie das Problem in diesem Fall behoben?
Kavi Vaidya
23

In meinem Fall hat mich das Lesen von Dokumenten von Apps von Drittanbietern ordnungsgemäß gerettet.

Der Täter? django_compressor

ich hatte

{% load compress %}
{% compress css %}
 ... css files linked here ..
{% endcompress %}

DEBUG = True gab mir immer 500. Um das Problem zu beheben, brauchte ich eine Zeile in meinen Einstellungen, um es zum Laufen zu bringen

COMPRESS_ENABLED = os.environ.get('COMPRESS_ENABLED', False)
KhoPhi
quelle
Danke, das war der Grund, warum es bei mir nicht funktioniert hat, aber deaktiviert diese Zeile django_compressor nicht daran, seine Arbeit zu erledigen?
Fanckush
1
@ Fanckush Nein. Es liegt kein Schaden vor. django-compressor.readthedocs.io/en/latest/settings/… Compressor würde seine Arbeit immer noch perfekt machen! Komprimieren Sie einfach alle Ihre Statiken (wie CSS), so dass die Einstellung somit nutzlos ist, da Ihre Assets bereits komprimiert sind
KhoPhi
13

Richtig, konfigurieren Sie in Django 1.5, wenn DEBUG = False, ALLOWED_HOSTS und fügen Sie Domänen ohne die Portnummer hinzu. Beispiel:

ALLOWED_HOSTS = ['localhost']
tonyprr
quelle
Aus irgendeinem Grund hat die Verwendung von 'localhost' bei mir nicht funktioniert. Ich musste stattdessen die IP '127.0.0.1' verwenden. Ich konnte auch '*' verwenden, wenn Sie ausflippen und nur möchten, dass es funktioniert. Ich würde jedoch nicht empfehlen, dies in der Produktion zu tun. OSX mit Django 1.4.20
BlakePetersen
11

Sie müssen auch Ihre URLs überall überprüfen. Wenn das auf gesetzt DEBUGist False, werden alle URLs ohne Trailing /als Fehler behandelt, anders als bei Ihnen DEBUG = True. In diesem Fall wird Django /überall dort angehängt, wo es fehlt. Kurz gesagt, stellen Sie sicher, dass alle Links ÜBERALL mit einem Schrägstrich enden.

webzy
quelle
3
Verwenden Sie einfach Reverse und URL-Tag und es sollte Ihnen gut gehen
Maazza
Einstellung DEBUG=Falsekann auch Importfehler
aufdecken
sogar Links zu JS- und CSS-Assets?
Amchugh89
@ Amchugh89: Nein, nur "Django" URLs
Webzy
1
Mein Problem ist, dass Whitenoise kein Bild finden konnte und ValueError auslöste. Ich konnte es auch nicht finden, wusste aber nicht, wie ich Whitenoise anweisen sollte, nicht danach zu suchen. Also habe ich Whitenoise ausgeschaltet, den statischen Django-Aufschlag verwendet und jetzt kann ich debug = False in prod ausführen. Offensichtlich nicht ideal :(
amchugh89
7

Ich habe eine lustige Geschichte für alle. Nachdem ich diese Seite erreicht hatte, sagte ich: "Eureka! Ich bin gerettet. Das muss mein Problem sein." Also habe ich die gewünschte ALLOWED_HOSTSListe in settings.py eingefügt und ... nichts. Gleicher alter 500er Fehler. Und nein, es fehlte nicht an einer 404.html-Datei.

Also beschäftigte ich mich 2 Tage lang mit wilden Theorien, zum Beispiel, dass es etwas mit dem Bereitstellen statischer Dateien zu tun hat (verstehe, dass ich ein Noob bin und Noobs nicht wissen, was sie tun).

Also was war es? Es ist jetzt Herr Moderator, dass wir zu einem nützlichen Tipp kommen. Während mein Entwicklungs-Django Version 1.5.something ist, ist meine Produktionsserver-Version 1.5.something + 1 ... oder vielleicht plus 2. Was auch immer. Nachdem ich ALLOWED_HOSTSdie Desktop-Version von settings.py hinzugefügt hatte , der das fehlte, was hwjp angefordert hatte - ein "Standardwert in settings.py, möglicherweise mit einem erklärenden Kommentar" -, tat ich dasselbe auf dem Produktionsserver mit die richtige Domain dafür.

Ich habe jedoch nicht bemerkt, dass auf dem Produktionsserver mit der späteren Version von Django in settings.py ein Standardwert mit einem erläuternden Kommentar vorhanden war. Es war weit unten, wo ich meinen Eintrag machte, außer Sicht auf dem Monitor. Und natürlich war die Liste leer. Daher meine Zeitverschwendung.

Mike O'Connor
quelle
1
Ich hatte genau das gleiche lustige Muster!, außer dass es erst komisch wurde, nachdem ich das gefunden hatte, danke. davor war es einfach nur frustrierend
binithb
Bei all dem hilft es, ein local_settings.pyfür jede Umgebung zu verwenden und es dann zu importieren settings.py.
Nicorellius
1
Was ich gerne mache, ist ein settings / Verzeichnis anstelle einer settings.py. In diesem Verzeichnis können Sie separate .py-Dateien für verschiedene Umgebungen und eine base.py für allgemeine Einstellungen haben. Produktionsabhängige Einstellungen können dann mit dem Importieren * aus den Basiseinstellungen beginnen und einfach alles überschreiben, was zum Überschreiben benötigt wird. Die erforderliche init .py , die erforderlich ist , um diese Einstellungen / dieses Verzeichnis in ein gültiges Modul umzuwandeln, kann zuerst aus base.py importiert und dann versucht werden, aus einer local.py zu importieren (die nur lokal vorhanden wäre). Das würde bedeuten, dass Sie die lokalen Einstellungen nicht manuell festlegen müssen
Mephisto
7

Ergänzung der Hauptantwort
Es ist ärgerlich, die globalen Konstanten ALLOWED_HOSTS und DEBUG settings.pybeim Wechsel zwischen Entwicklung und Produktion zu ändern . Ich verwende diesen Code, um diese Einstellungen automatisch festzulegen:

import socket

if socket.gethostname() == "server_name":
    DEBUG = False
    ALLOWED_HOSTS = [".your_domain_name.com",]
    ...
else:
    DEBUG = True
    ALLOWED_HOSTS = ["localhost", "127.0.0.1",]
    ...

Wenn Sie macOS verwenden, können Sie einen allgemeineren Code schreiben:

if socket.gethostname().endswith(".local"): # True in your local computer
    DEBUG = True
    ALLOWED_HOSTS = ["localhost", "127.0.0.1",]
else:
    ...
ePi272314
quelle
6

Für das, was es wert ist - ich habe DEBUG = Falsenur auf einigen Seiten eine 500 bekommen . Das Zurückverfolgen der Ausnahme mit pdb ergab ein fehlendes Asset (ich vermute, dass das {% static ... %}Template-Tag der Schuldige für die 500 war.

user316054
quelle
1
Dies war auch mein Problem. Die Basisvorlage, auf die auf der benutzerdefinierten 404-Seite verwiesen wurde, verwendete das statische Tag, enthielt jedoch nicht das {% load static%} oben. Ich habe es an anderer Stelle nicht bemerkt, weil meine anderen Vorlagen diese Zeile hatten, aber es ist trotzdem sinnvoll, sie in die Basis zu stellen, da sie sich überall auf statische Dateien bezieht.
Krischan
2
Gleiche Lösung hier - Ich habe staticeine CSS-Datei eingefügt, die nicht vorhanden war.
Phil Gyford
5

Ich hatte das gleiche Problem, als ich es tat DEBUG = FALSE. Hier ist eine konsolidierte Lösung, die in den obigen Antworten und anderen Beiträgen verstreut ist.

Standardmäßig haben wir in settings.py ALLOWED_HOSTS = []. Hier sind mögliche Änderungen, die Sie ALLOWED_HOSTSgemäß Szenario vornehmen müssen, um den Fehler zu beheben:

1: Ihr Domainname:

ALLOWED_HOSTS = ['www.example.com'] # Your domain name here

2: Ihre bereitgestellte Server-IP, wenn Sie noch keinen Domainnamen haben (was mein Fall war und wie ein Zauber funktioniert hat):

ALLOWED_HOSTS = ['123.123.198.123'] # Enter your IP here

3: Wenn Sie auf lokale Server testen, können Sie bearbeiten settings.pyoder settings_local.pyals:

ALLOWED_HOSTS = ['localhost', '127.0.0.1']

4: Sie können im ALLOWED_HOSTSWert auch '*' angeben, dies wird jedoch aus Sicherheitsgründen in der Produktionsumgebung nicht empfohlen :

ALLOWED_HOSTS = ['*'] # Not recommended in production environment

Ich habe auch eine detaillierte Lösung in meinem Blog veröffentlicht, auf die Sie möglicherweise verweisen möchten.

Ali Raza Bhayani
quelle
5

ALLOWED_HOSTS ist NICHT das einzige Problem. Für mich musste ich eine 404.html erstellen und in die Basisebene meiner Vorlagen einfügen (keine App-Ebene). Sie können auch eine 404-Ansicht erstellen und eine 404-Handler-URL hinzufügen, aber ich denke, das ist es Optional. 404.html hat es behoben

in mainproject.urls

handler404 = 'app.views.custom_404'

in app.views

def custom_404(request):
    return render(request, '404.html', {}, status=404)

Erstellen Sie dann eine Vorlage / 404.html

Ich habe dies von einem anderen S / O-Beitrag erhalten, den ich nicht finden kann

BEARBEITEN

Außerdem erhalte ich 500 Fehler, wenn ich Assets mit Whitenoise bediene. Konnte nicht herausfinden, dass ValueError von whitenoise für mein Leben nicht in der Lage war, ein Asset zu finden, das ich auch nicht finden konnte

amchugh89
quelle
8
Ich hatte das gleiche Problem mit Weißfärbung. python manage.py collectstaticbehoben.
Eugene Pakhomov
1
@ amchungh89 du bist ein Lebensretter! Vielen Dank für den Hinweis.
Deepak Sharma
5

Ich habe mehr über dieses Problem gesucht und getestet und festgestellt, dass statische Dateiverzeichnisse, die in settings.py angegeben sind, eine Ursache dafür sein können. Daher müssen wir diesen Befehl zunächst ausführen

python manage.py collectstatic

In settings.py sollte der Code ungefähr so ​​aussehen:

STATIC_URL = '/static/'

STATICFILES_DIRS = (
    os.path.join(BASE_DIR, 'static'),
)

STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
Edison Urquijo
quelle
3

Ich weiß, dass dies eine super alte Frage ist, aber vielleicht könnte ich jemand anderem helfen. Wenn nach dem Setzen von DEBUG = False ein Fehler von 500 auftritt, können Sie den runserver manage.py jederzeit in der Befehlszeile ausführen, um Fehler anzuzeigen, die in Webfehlerprotokollen nicht angezeigt werden.

n0grip
quelle
2

Es ist Mitte 2019 und ich hatte diesen Fehler nach einigen Jahren der Entwicklung mit Django. Hat mich eine ganze Nacht verwirrt! Es war nicht erlaubt, dass der Host (der eine 400 werfen sollte), alles andere ausgecheckt, schließlich eine Fehlerprotokollierung durchgeführt wurde, nur um festzustellen, dass einige fehlende / oder durcheinandergebrachte statische Dateien (nach collectstatic) mit dem Setup verschraubt waren. Lange Rede, kurzer Sinn, für diejenigen, die ratlos sind und SO PASSIEREN WHITENOISE oder das DJANGO STATICFILE BACKEND WITH CACHE (Manifest Static Files) verwenden, ist dies vielleicht das Richtige für Sie.

  1. Stellen Sie sicher, dass Sie alles einrichten (wie ich es für das Whitenoise-Backend getan habe ... Django-Backends lesen Sie trotzdem weiter) http://whitenoise.evans.io/en/stable/django.html

  2. Wenn der Fehlercode 500 Sie immer noch abschießt, notieren Sie sich Ihre Einstellungen.STATICFILES_STORAGE.

Stellen Sie entweder ein (für weißes Backend mit Komprimierung)

STATICFILES_STORAGE = 'whitenoise.storage.CompressedStaticFilesStorage'

oder (als Django-Standardeinstellung belassen)

STATICFILES_STORAGE = django.contrib.staticfiles.storage.StaticFilesStorage

Alles in allem schien THE PROBLEM von der Tatsache zu stammen, dass dieser Whitenoise-Cache + Komprimierungs-Backend ->

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

oder das eigene Caching-Backend des Django ->

STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'

... hat für mich nicht ganz gut funktioniert, da mein CSS auf einige andere Quellen verwies, die während des Caching von Collectstatic / Backend verwechselt werden könnten. Dieses Problem wird möglicherweise auch in http://whitenoise.evans.io/en/stable/django.html#storage-troubleshoot hervorgehoben

Aaronlhe
quelle
1

Ich denke, es könnten auch die http-Servereinstellungen sein. Meins ist immer noch kaputt und hatte die ganze Zeit ALLOWED_HOSTS. Ich kann lokal darauf zugreifen (ich benutze Gunicorn), aber nicht über den Domainnamen, wenn DEBUG = False. Wenn ich versuche, den Domainnamen zu verwenden, wird mir der Fehler angezeigt, sodass ich denke, dass es sich um ein Nginx-Problem handelt.

Hier ist meine Conf-Datei für Nginx:

server {
    listen   80;
    server_name localhost myproject.ca www.myproject.ca;
    root /var/web/myproject/deli_cms;

    # serve directly - analogous for static/staticfiles
    location /media/ {
        # if asset versioning is used
        if ($query_string) {
            expires max;
        }
    }
    location /admin/media/ {
        # this changes depending on your python version
        root /var/web/myproject/lib/python2.6/site-packages/django/contrib;
    }
    location /static/ {
    alias /var/web/myproject/deli_cms/static_root/;
    }

    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_connect_timeout 10;
        proxy_read_timeout 10;
        proxy_pass http://localhost:8000/;
    }
    # what to serve if upstream is not available or crashes
    error_page 500 502 503 504 /media/50x.html;
}
user2868304
quelle
Meine Gunicorn-Konfigurationsdatei lautet wie folgt: #! / bin / bash cd / var / web / delicms_env / deli_cms / source ../bin/activate exec gunicorn --workers = 3 deli_cms.wsgi: application
user2868304
Mein Problem ist jetzt gelöst. Ich habe das Skript gunicorn_django verwendet und es hat mir veraltete Nachrichten gegeben. Ich bin mir immer noch nicht sicher, warum es lokal funktioniert hat. Ich habe meine Nginx-Konfiguration nicht geändert. Ich habe nur das alte Skript geändert, um Gunicorn zu verwenden und stattdessen das Anwendungsmodul wsgi: zu verwenden, und es funktioniert wieder. Gunicorn warf auch vorher einige Abwertungsnachrichten, aber nichts Spezielles für mein Problem.
user2868304
1

Ich habe ein ähnliches Problem, in meinem Fall wurde es durch ein kommentiertes Skript im Body-Tag verursacht.

<!--<script>  </script>-->
Edison Urquijo
quelle
1

Ich bin auf dieses Problem gestoßen. Es stellte sich heraus, dass ich mithilfe des staticVorlagen-Tags eine Datei in die Vorlage aufgenommen habe, die nicht mehr vorhanden war. Ein Blick in die Protokolle zeigte mir das Problem.

Ich denke, dies ist nur einer von vielen möglichen Gründen für diese Art von Fehler.

Moral der Geschichte: Immer Fehler protokollieren und Protokolle immer überprüfen.

Nishant George Agrwal
quelle
1

Dank @squarebear habe ich in der Protokolldatei den Fehler gefunden : ValueError: The file 'myapp/styles.css' could not be found with <whitenoise.storage.CompressedManifestStaticFilesStorage ...>.

Ich hatte einige Probleme mit meiner Django-App. Ich entfernte die Zeile,
STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage'die ich gefunden hatte, aus der Dokumentation des Heroku.

Ich musste auch ein zusätzliches Verzeichnis (dank einer anderen SO-Antwort ) staticim Stammverzeichnis der Django-Anwendung hinzufügen myapp/static, obwohl ich es nicht benutzte. Durch Ausführen des Befehls python manage.py collectstaticvor dem Ausführen des Servers wurde das Problem behoben. Endlich fing es an gut zu funktionieren.

kHarshit
quelle
Wie beantwortet dies die ursprüngliche Frage?
Nick
1

Ich fing an, die 500 für debug = False in Form von zu bekommen

django.urls.exceptions.NoReverseMatch: Reverse for 'home' not found.
or...
django.urls.exceptions.NoReverseMatch: Reverse for 'about' not found.

beim Auslösen von django.core.exceptions.ValidationError anstelle von rest_framework.serializers.ValidationError

Um fair zu sein, hat es bereits zuvor 500 ausgelöst, aber als ValidationError mit debug = False wurde dies in NoReverseMatch geändert.

DZet
quelle
1

Dies kann vielleicht jemand anderem helfen, in meinem Fall das Problem mit dem fehlenden Favicon.

DAMAR225
quelle
0

Ich weiß, dass dies eine alte Frage ist, aber ich habe auch einen Fehler von 500 erhalten, wenn DEBUG = False. Nach einigen Stunden wurde mir klar, dass ich vergessen hatte, einige der Links in meiner base.html mit einem abschließenden Schrägstrich zu beenden.

SethB
quelle
sogar das CSS und JS Zeug?
Amchugh89
0

Dies ist alt und mein Problem hing letztendlich mit dem Problem zusammen, aber nicht mit dem OP, aber meine Lösung ist für alle anderen, die das oben Genannte erfolglos versucht haben.

Ich hatte eine Einstellung in einer modifizierten Version von Django, um CSS- und JS-Dateien zu minimieren, die nur ausgeführt wurden, wenn DEBUG deaktiviert war. Auf meinem Server war der CSS-Minifier nicht installiert und der Fehler wurde ausgelöst. Wenn Sie Django-Mako-Plus verwenden, ist dies möglicherweise Ihr Problem.

Spartacus
quelle
0

Eine kleine Sache zu beachten: Wenn das Array None enthält, werden alle nachfolgenden zulässigen Hosts ignoriert.

ALLOWED_HOSTS = [
    "localhost",
    None,
    'example.com', # First DNS alias (set up in the app)
    #'www.example.com', # Second DNS alias (set up in the app)
]

Django version 1.8.4

Ayush Goel
quelle
0

Ein bisschen zu spät zur Party, und natürlich könnte es eine Legion von Problemen geben, aber ich hatte ein ähnliches Problem und es stellte sich heraus, dass ich {%%} Sonderzeichen in meiner HTML-Bemerkung hatte ...

<!-- <img src="{% static "my_app/myexample.jpg" %}" alt="My image"/> -->
Nico van Niekerk
quelle
0

Ich hatte eine Ansicht, die einen 500-Fehler in debug = false auslöste, aber in debug = true funktionierte. Für alle, die so etwas bekommen und zulässige Hosts nicht das Problem sind, habe ich meine Ansicht korrigiert, indem ich das statische Tag einer Vorlage aktualisiert habe, das auf den falschen Speicherort zeigte.

Daher würde ich vorschlagen, nur zu überprüfen, ob Links und Tags in allen verwendeten Vorlagen luftdicht sind. Vielleicht rutschen bestimmte Dinge beim Debuggen durch das Netz, geben aber Fehler in der Produktion.

Tom
quelle
0

Ich habe eine weitere Ursache für den 500-Fehler gefunden, wenn DEBUG = False. Ich verwende das Django- compressorDienstprogramm und unser Front-End-Techniker hat Verweise auf Schriftdateien in einem compress cssBlock in einer Django-Vorlage hinzugefügt . So was:

{% compress css %}
    <link href="{% static "css/bootstrap.css" %}" rel="stylesheet">
    <link href="{% static "css/bootstrap-spinedit.css" %}" rel="stylesheet">
    <link href="{% static "djangular/css/styles.css" %}" rel="stylesheet">
    <link href="{% static "fonts/fontawesome-webfont.ttf" %}" rel="stylesheet">
{% endcompress %}

Die Lösung bestand darin, den Link zu der ttfDatei unterhalb der endcompressZeile zu verschieben.

nmgeek
quelle
0

Ich hatte ein ähnliches Problem und werde berichten, wie ich mein Problem gelöst habe, weil es sein könnte, dass jemand das gleiche erlebt.

In meinem Fall wurde der Fehler verursacht, weil der Server einige statische Dateien von der Homepage nicht gefunden hat.

Stellen Sie daher sicher, dass der Fehler nur auf der indexoder auf einer anderen Seite auftritt. Wenn das Problem nur im Index auftritt, müssen Sie höchstwahrscheinlich die statischen Dateien überprüfen. Ich empfehle, die Chrome-Vorschau-Konsole zu öffnen und nach Fehlern zu suchen.

In meinem Fall konnte der Server favicon.icound zwei andere CSS nicht finden .

Um dies zu beheben, habe ich bestanden python manage.py collectstaticund es hat funktioniert.

Alison Andrade
quelle
0

Ich weiß, dass dieser Beitrag ziemlich alt ist, aber er ist heute noch vollkommen relevant.

Für das, was es wert ist - ich habe 500 DEBUG = Falsefür alle Seiten meiner Website erhalten.

Ich habe beim Debuggen kein Traceback erhalten.

Ich musste jeden statischen Link in meinen Vorlagen auf meiner Website durchgehen und fand einen / (Schrägstrich) vor meiner Bildquelle. {% static ...%}. Dies verursachte den 500-Fehler DEBUG = False, funktionierte aber Debug = Trueohne Fehler einwandfrei . Sehr nervig! Sei gewarnt! Viele Stunden Zeitverschwendung durch einen Schrägstrich ...

E Wilson
quelle
0

Vielleicht möchten Sie laufen , python manage.py collectstaticnachdem Sie gesetzt DEBUG = Falseund ALLOWED_HOSTS = ['127.0.0.1']in settings.py. Nach diesen beiden Schritten lief meine Webanwendung auf meinem lokalen Server auch im DEBUG = False-Modus einwandfrei.

Übrigens habe ich diese Einstellungen in settings.py.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware', # what i added
    'django.middleware.common.CommonMiddleware', # and so on...
]

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

Ich gehe davon aus, dass die Einstellung Weißweiß möglicherweise etwas mit dem Befehl collectstatic zu tun hat.

Harry
quelle
-3

Ok, nachdem Sie so viele Dinge ausprobiert haben, ist die richtige Lösung ...

Sie müssen DEBUG = 'FALSE'nicht Falseoder FALSE, sondern 'FALSE'mit einstellen''

xGoPox
quelle
Ich denke, 'FALSE' ist eine Zeichenfolge, daher ist sie gleich True. Deshalb wird kein Fehler angezeigt.
Apet