La définition de DEBUG = False provoque une erreur 500
Une fois que j'ai changé le DEBUG = False, mon site générera 500 (en utilisant wsgi & manage.py runserver), et il n'y a aucune information d'erreur dans le journal des erreurs Apache et il s'exécutera normalement lorsque je changerai debug en True.
J'utilise Django 1.5 & Python 2.7.3 Voici le journal des accès Apache et sans aucun journal dans le journal des erreurs Apache
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"
Voici mon fichier de paramètres:
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',
)
Django 1.5 a introduit le paramètre allowed hosts requis pour des raisons de sécurité. Un fichier de paramètres créé avec Django 1.5 contient cette nouvelle section que vous devez ajouter:
# 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 = []
Ajoutez votre hôte ici comme ['www.beta800.net'] ou ['*'] pour un test rapide, mais n'utilisez pas ['*'] pour la production .
Je sais que c'est tard mais je me suis retrouvé ici avec une recherche de mon erreur 500 avec DEBUG=False; dans mon cas, il s'est avéré que c'était le ALLOWED_HOSTS mais j'utilisais os.environ.get('variable') pour remplir les hôtes, je ne l'avais pas remarqué avant d'activer la journalisation. , vous pouvez enregistrer toutes les erreurs dans le fichier ci-dessous et celui-ci sera enregistré même lorsque 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',
},
}
}
Dans mon cas, lire des documents d'applications tierces m'a correctement sauvé.
Le coupable? Django_compressor
J'ai eu
{% load compress %}
{% compress css %}
... css files linked here ..
{% endcompress %}
DEBUG = True m'a toujours donné 500. Pour y remédier, j'avais besoin d'une ligne dans mes paramètres pour le faire fonctionner
COMPRESS_ENABLED = os.environ.get('COMPRESS_ENABLED', False)
A droite, dans Django 1.5 si DEBUG = False, configurez ALLOWED_HOSTS, en ajoutant des domaines sans le numéro de port. Exemple:
ALLOWED_HOSTS = ['localhost']
J'ai rencontré le même problème récemment dans Django 2.0. J'ai pu résoudre le problème en définissant DEBUG_PROPAGATE_EXCEPTIONS = True. Voir ici: https://docs.djangoproject.com/fr/2.0/ref/settings/#debug-propagate-exceptions
Dans mon cas, l'erreur était ValueError: Missing staticfiles manifest entry for 'admin/css/base.css'. J'ai corrigé cela en exécutant localement python manage.py collectstatic.
Vous devez également vérifier vos URL partout. Lorsque DEBUG est défini sur False, toutes les URL sans / final sont traitées comme des bogues, contrairement à DEBUG = True, auquel cas Django ajoutera / partout où il manque. Donc, en bref, assurez-vous que tous les liens se terminent par une barre oblique PARTOUT.
J'ai une histoire hilarante pour tous. Après avoir atteint cette page, j'ai dit "Eureka! Je suis sauvé. Ce doit être mon problème." J'ai donc inséré la liste ALLOWED_HOSTS requise dans setting.py et ... rien. Même vieille erreur 500. Et non, ce n'était pas faute d'un fichier 404.html.
Alors, pendant 2 jours, je me suis occupé de théories farfelues, telles que le fait de servir des fichiers statiques (comprenez que je suis un noob et que les noobs ne savent pas ce qu’ils font).
Alors c'était quoi? C’est maintenant à Monsieur le Modérateur que nous arrivons à un conseil utile. Alors que mon développement Django est la version 1.5.quelque chose, la version de mon serveur de production est 1.5.quelque chose + 1 ... ou peut-être plus 2. Peu importe. Et donc après avoir ajouté le ALLOWED_HOSTS à la version de settings.py sur le bureau, qui manquait de ce que hwjp demandait - une "valeur par défaut dans settings.py, peut-être avec un commentaire explicatif" - j'ai fait de même sur le serveur de production avec le domaine approprié.
Mais je n’ai pas remarqué que sur le serveur de production doté de la dernière version de Django, il existait une valeur par défaut dans settings.py avec un commentaire explicatif. C'était bien en dessous de l'endroit où j'ai fait mon entrée, à l'abri des regards sur l'écran. Et bien sûr, la liste était vide. D'où ma perte de temps.
Pour ce que ça vaut - je recevais un 500 avec DEBUG = False sur certaines pages seulement. Le suivi de l’exception avec pdb a révélé un actif manquant (je soupçonne que la balise de modèle {% static ... %} était le coupable du 500.
Complétant la réponse principale
Il est agaçant de changer les constantes globales ALLOWED_HOSTS et DEBUG dans settings.py lors du basculement entre développement et production . J'utilise ce code pour définir ces paramètres automatiquement:
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",]
...
Si vous utilisez macOS, vous pourriez écrire un code plus générique:
if socket.gethostname().endswith(".local"): # True in your local computer
DEBUG = True
ALLOWED_HOSTS = ["localhost", "127.0.0.1",]
else:
...
J'ai rencontré le même problème quand j'ai fait DEBUG = FALSE. Voici une solution consolidée, dispersée dans les réponses ci-dessus et d’autres publications.
Par défaut, dans settings.py, nous avons ALLOWED_HOSTS = []. Voici les modifications que vous devrez apporter dans la valeur ALLOWED_HOSTS selon le scénario pour supprimer l'erreur:
1: Votre nom de domaine:
ALLOWED_HOSTS = ['www.example.com'] # Your domain name here
2: Votre adresse IP de serveur déployée si vous n'avez pas encore de nom de domaine (ce qui était mon cas et a fonctionné à merveille):
ALLOWED_HOSTS = ['123.123.198.123'] # Enter your IP here
3: Si vous testez sur un serveur local, vous pouvez modifier votre settings.py ou settings_local.py comme suit:
ALLOWED_HOSTS = ['localhost', '127.0.0.1']
4: Vous pouvez également fournir '*' dans la valeur ALLOWED_HOSTS mais son non recommandé dans l'environnement de production pour des raisons de sécurité:
ALLOWED_HOSTS = ['*'] # Not recommended in production environment
J'ai également posté une solution détaillée sur mon blog que vous voudrez peut-être consulter.
ALLOWED_HOSTS n’est PAS le seul problème. Pour moi, j’ai dû créer un fichier 404.html et le placer au niveau de base de mes modèles (pas au niveau de l’application). optionnel. 404.html corrigé
dans mainproject.urls
handler404 = 'app.views.custom_404'
dans app.views
def custom_404(request):
return render(request, '404.html', {}, status=404)
faites ensuite un template/404.html
obtenu cela d'un autre poste S/O que je ne peux pas le trouver
MODIFIER
de plus, je reçois 500 erreurs lorsque je sers des ressources avec Whitenoise. Je ne pouvais pas comprendre cela pendant toute ma vie, erreur était ValueError de whitenoise ne pas être en mesure de trouver un actif que je ne pouvais pas trouver, a dû aller avec défaut Django servant pour l'instant
Je cherchais et testais plus sur ce problème et je me suis rendu compte que les fichiers statiques direcotiries spécifiés dans settings.py peuvent en être la cause.
python manage.py collecstatic
dans settings.py, le code devrait ressembler à ceci:
STATIC_URL = '/static/'
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
Je sais que c'est une très vieille question, mais je pourrais peut-être aider quelqu'un d'autre. Si vous rencontrez une erreur 500 après avoir défini DEBUG = False, vous pouvez toujours exécuter le serveur d'exécution manage.py dans la ligne de commande pour afficher les erreurs ne figurant pas dans les journaux d'erreur Web.
Merci à @squarebear, dans le fichier journal, j'ai trouvé l'erreur: ValueError: The file 'myapp/styles.css' could not be found with <whitenoise.storage.CompressedManifestStaticFilesStorage ...>.
J'ai eu quelques problèmes dans mon application Django. J'ai enlevé la ligneSTATICFILES_STORAGE = 'whitenoise.Django.GzipManifestStaticFilesStorage' que j'ai trouvé dans la documentation de heroku.
J'ai également dû ajouter un répertoire supplémentaire (grâce à une autre réponse SO ) static à la racine de l'application Django en tant que myapp/static même si je ne l'utilisais pas. Ensuite, l’exécution de la commande python manage.py collectstatic avant d’exécuter le serveur a résolu le problème. Finalement, cela a bien fonctionné.
Je pense que cela pourrait aussi être les paramètres du serveur http. Le mien est toujours cassé et a ALLOWED_HOSTS depuis le début Je peux y accéder localement (j'utilise gunicorn), mais pas via le nom de domaine lorsque DEBUG = False. Lorsque j'essaie d'utiliser le nom de domaine, cela me donne l'erreur, ce qui me fait penser que c'est un problème lié à Nginx.
Voici mon fichier de configuration pour 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;
}
J'ai rencontré ce problème. Il s'avère que j'ai inclus dans le modèle, à l'aide de la balise de modèle static, un fichier qui n'existe plus Un coup d'oeil dans les journaux m'a montré le problème.
Je suppose que ceci n’est qu’une des nombreuses raisons possibles de ce type d’erreur.
Morale de l'histoire: enregistrez toujours les erreurs et vérifiez toujours les journaux.
J'ai commencé à obtenir le 500 pour le débogage = False sous la forme de
Django.urls.exceptions.NoReverseMatch: Reverse for 'home' not found.
or...
Django.urls.exceptions.NoReverseMatch: Reverse for 'about' not found.
lors de la levée Django.core.exceptions.ValidationError au lieu de la levée rest_framework.serializers.ValidationError
Pour être honnête, il levait déjà 500 avant, mais en tant que ValidationError, avec debug = False, cela a changé en NoReverseMatch.
J'ai le même problème, dans mon cas, cela est dû à la présence d'un script commenté dans la balise body.
<!--<script> </script>-->
Une petite chose à noter, si le tableau ne contient aucun, tous les hôtes autorisés suivants sont ignorés.
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
J'ai eu un problème similaire à celui-ci et je vais raconter comment j'ai résolu le mien car il se pourrait que quelqu'un éprouve également les mêmes problèmes.
Dans mon cas, l'erreur était due au fait que le serveur ne trouvait pas certains fichiers statiques dans la page d'accueil.
Veillez donc à ce que l'erreur ne se produise que dans index ou sur une autre page. Si le problème ne survient que très probablement dans l'index, vous devez vérifier les fichiers statiques. Je recommande d'ouvrir la console de prévisualisation Chrome et de rechercher d'éventuelles erreurs.
Dans mon cas, le serveur n'a pas été trouvé favicon.ico et deux autres fichiers CSS.
En corrigeant cela, j'ai donné un python manage.py collecstatic et corrigé le problème.
J'ai trouvé encore une autre cause de l'erreur 500 lorsque DEBUG = False. J'utilise l'utilitaire Django compressor et notre ingénieur frontal a ajouté des références aux fichiers de polices inside un bloc compress css dans un modèle Django. Comme ça:
{% 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 %}
La solution consistait à déplacer le lien dans le fichier ttf sous la ligne endcompress.
Un peu tard pour la fête, et bien sûr il pourrait y avoir une légion de problèmes, mais j'ai eu un problème similaire et il s'est avéré que j'avais {%%} des caractères spéciaux dans ma remarque html ...
<!-- <img src="{% static "my_app/myexample.jpg" %}" alt="My image"/> -->
Je sais que c’est une vieille question, mais j’obtenais également une erreur 500 lorsque DEBUG = False. Après plusieurs heures, j'ai réalisé que j'avais oublié de mettre fin à certains liens de ma base.html avec un slash final.
J'ai eu une vue qui a jeté une erreur 500 dans debug = false mais a travaillé dans debug = true. Pour ceux qui obtiennent ce genre de chose et que le problème Hôtes autorisés n'est pas le problème, j'ai résolu mon problème en mettant à jour la balise statique d'un modèle pointant vers le mauvais emplacement.
Je suggérerais donc de vérifier que les liens et les balises sont hermétiques dans tous les modèles utilisés. Certaines choses glissent peut-être à travers le filet lors du débogage, mais donnent des erreurs de production.
C'est au milieu de 2019 et j'ai fait face à cette erreur après quelques années de développement avec Django. M'a dérouté pendant une nuit entière! Ce n'était pas autorisé Host (qui devrait lancer un 400), tout le reste a été vérifié, a finalement fait une erreur de journalisation pour découvrir que certains fichiers statiques manquants/ou égarés (après collectstatic) étaient foutus avec l'installation. Bref, pour ceux qui sont perplexes ET SO HAPPEN UTILISE WHITENOISE OR LE BACKGAME STATICFILE de Django avec CACHE (fichiers statiques manifestes), c'est peut-être pour vous.
Assurez-vous de tout configurer (comme je l’ai fait pour le backend whitenoise ... Le backend Django est néanmoins lu) http://whitenoise.evans.io/en/stable/Django.html
Si le code d'erreur 500 vous abat encore, prenez note de vos paramètres.STATICFILES_STORAGE.
Réglez-le sur l'un ou l'autre (pour le backend blanc avec compression)
STATICFILES_STORAGE = 'whitenoise.storage.CompressedStaticFilesStorage'
ou (laisser comme Django par défaut)
STATICFILES_STORAGE = Django.contrib.staticfiles.storage.StaticFilesStorage
Dans l’ensemble, LE PROBLÈME semblait provenir du fait que ce cache blanc + back-end de compression ->
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
ou le backend de mise en cache de Django ->
STATICFILES_STORAGE = 'Django.contrib.staticfiles.storage.ManifestStaticFilesStorage'
... n'a pas très bien fonctionné pour moi, car mon css faisait référence à d'autres sources qui pourraient être mélangées lors de la mise en cache collectstatic/backend. Ce problème est également potentiellement souligné dans http://whitenoise.evans.io/en/stable/Django.html#storage-troubleshoot
C'est vieux et mon problème a fini par être lié au problème mais pas pour le PO mais ma solution est pour toute autre personne qui a essayé la solution ci-dessus sans succès.
J'avais un paramètre dans une version modifiée de Django pour minimiser les fichiers CSS et JS qui ne s'exécutaient que lorsque DEBUG était désactivé. Mon serveur n'a pas eu le minifier CSS installé et a jeté l'erreur. Si vous utilisez Django-Mako-Plus, cela pourrait être votre problème.