Django: ImproperlyConfigured: Le paramètre SECRET_KEY ne doit pas être vide

101

J'essaye de mettre en place plusieurs fichiers de configuration (développement, production, ..) qui incluent certains paramètres de base. Impossible de réussir cependant. Lorsque j'essaye de courir ./manage.py runserver, j'obtiens l'erreur suivante:

(cb)clime@den /srv/www/cb $ ./manage.py runserver
ImproperlyConfigured: The SECRET_KEY setting must not be empty.

Voici mon module de paramètres:

(cb)clime@den /srv/www/cb/cb/settings $ ll
total 24
-rw-rw-r--. 1 clime clime 8230 Oct  2 02:56 base.py
-rw-rw-r--. 1 clime clime  489 Oct  2 03:09 development.py
-rw-rw-r--. 1 clime clime   24 Oct  2 02:34 __init__.py
-rw-rw-r--. 1 clime clime  471 Oct  2 02:51 production.py

Paramètres de base (contiennent SECRET_KEY):

(cb)clime@den /srv/www/cb/cb/settings $ cat base.py:
# Django base settings for cb project.

import django.conf.global_settings as defaults

DEBUG = False
TEMPLATE_DEBUG = False

INTERNAL_IPS = ('127.0.0.1',)

ADMINS = (
    ('clime', '[email protected]'),
)

MANAGERS = ADMINS

DATABASES = {
    'default': {
        #'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'cwu',                   # Or path to database file if using sqlite3.
        'USER': 'clime',                 # Not used with sqlite3.
        'PASSWORD': '',                  # 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 = 'Europe/Prague'

# 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 = False

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = False # TODO: make this true and accustom date time input

DATE_INPUT_FORMATS = defaults.DATE_INPUT_FORMATS + ('%d %b %y', '%d %b, %y') # + ('25 Oct 13', '25 Oct, 13')

# 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 = '/srv/www/cb/media'

# 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 = '/media/'

# 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 = '/srv/www/cb/static'

# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'

# 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.
)

# 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 = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'

# 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',
)

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.contrib.auth.context_processors.auth',
    'django.core.context_processors.request',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.static',
    'django.core.context_processors.tz',
    'django.contrib.messages.context_processors.messages',
    'web.context.inbox',
    'web.context.base',
    'web.context.main_search',
    'web.context.enums',
)

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',
    'watson.middleware.SearchContextMiddleware',
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'middleware.UserMemberMiddleware',
    'middleware.ProfilerMiddleware',
    'middleware.VaryOnAcceptMiddleware',
    # Uncomment the next line for simple clickjacking protection:
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

ROOT_URLCONF = 'cb.urls'

# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'cb.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.
    '/srv/www/cb/web/templates',
    '/srv/www/cb/templates',
)

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'south',
    'grappelli', # must be before admin
    'django.contrib.admin',
    'django.contrib.admindocs',
    'endless_pagination',
    'debug_toolbar',
    'djangoratings',
    'watson',
    'web',
)

AUTH_USER_MODEL = 'web.User'

# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'formatters': {
        'standard': {
            'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
            'datefmt' : "%d/%b/%Y %H:%M:%S"
        },
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
        },
        'null': {
            'level':'DEBUG',
            'class':'django.utils.log.NullHandler',
        },
        'logfile': {
            'level':'DEBUG',
            'class':'logging.handlers.RotatingFileHandler',
            'filename': "/srv/www/cb/logs/application.log",
            'maxBytes': 50000,
            'backupCount': 2,
            'formatter': 'standard',
        },
        'console':{
            'level':'INFO',
            'class':'logging.StreamHandler',
            'formatter': 'standard'
        },
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        'django': {
            'handlers':['console'],
            'propagate': True,
            'level':'WARN',
        },
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
        'web': {
            'handlers': ['console', 'logfile'],
            'level': 'DEBUG',
        },
    },
}

LOGIN_URL = 'login'
LOGOUT_URL = 'logout'

#ENDLESS_PAGINATION_LOADING = """
#    <img src="/static/web/img/preloader.gif" alt="loading" style="margin:auto"/>
#"""
ENDLESS_PAGINATION_LOADING = """
    <div class="spinner small" style="margin:auto">
        <div class="block_1 spinner_block small"></div>
        <div class="block_2 spinner_block small"></div>
        <div class="block_3 spinner_block small"></div>
    </div>
"""

DEBUG_TOOLBAR_CONFIG = {
    'INTERCEPT_REDIRECTS': False,
}

import django.template.loader
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
django.template.loader.add_to_builtins('web.templatetags.tag_library')

WATSON_POSTGRESQL_SEARCH_CONFIG = 'public.english_nostop'

Un des fichiers de paramètres:

(cb)clime@den /srv/www/cb/cb/settings $ cat development.py 
from base import *

DEBUG = True
TEMPLATE_DEBUG = True

ALLOWED_HOSTS = ['127.0.0.1', '31.31.78.149']

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'cwu',
        'USER': 'clime',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

MEDIA_ROOT = '/srv/www/cb/media/'

STATIC_ROOT = '/srv/www/cb/static/'

TEMPLATE_DIRS = (
    '/srv/www/cb/web/templates',
    '/srv/www/cb/templates',
)

Code en manage.py:

(cb)clime@den /srv/www/cb $ cat manage.py 
#!/usr/bin/env python
import os
import sys

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cb.settings.development")

    from django.core.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Si j'ajoute from base import *dans /srv/www/cb/cb/settings/__init__.py(qui est autrement vide), cela commence par magie à fonctionner mais je ne comprends pas pourquoi. N'importe qui pourrait m'expliquer ce qui se passe ici? Ce doit être une magie du module python.

EDIT: Tout commence également à fonctionner si je supprime cette ligne de base.py

django.template.loader.add_to_builtins('web.templatetags.cb_tags')

Si je supprime cette ligne de web.templatetags.cb_tags, cela commence également à fonctionner:

from endless_pagination.templatetags import endless

Je suppose que c'est parce que, à la fin, cela conduit à

from django.conf import settings
PER_PAGE = getattr(settings, 'ENDLESS_PAGINATION_PER_PAGE', 10)

Cela crée donc des trucs circulaires étranges et le jeu est terminé.

climat
la source
Exactement, à la fin, vous aurez toujours besoin de paramètres, même si cela provient de django.conf
Guilherme David da Costa
2
Essayez de changer votre DJANGO_SETTINGS_MODULE en settings.development
Guilherme David da Costa
Quiconque utilise virutalenvwrapper essaie la réponse de crimeminister sur stackoverflow.com/questions/10738919/…
lukeaus

Réponses:

107

J'ai eu la même erreur et il s'est avéré qu'il s'agissait d'une dépendance circulaire entre un module ou une classe chargé par les paramètres et le module de paramètres lui-même. Dans mon cas, c'était une classe middleware nommée dans les paramètres qui tentait elle-même de charger les paramètres.

Sam Svenbjorgchristiensensen
la source
4
Oui, je pense que la circularité le fait.
clime
5
Refactoriser pour éviter la dépendance circulaire. La solution exacte est vraiment assez spécifique à votre propre code.
Sam Svenbjorgchristiensensen
6
Astuce: pour identifier la cause du problème, par exemple, ajoutez une instruction d'impression aléatoire dans le fichier de paramètres et déplacez-la pour voir où elle se rompt.
Felix Böhme
16
Je n'ai pas trouvé de réponse à cela.
Avinash Raj
8
Cette réponse serait plus utile si elle était plus précise ... elle dit que le problème est "quelque chose".
Hack-R
73

J'ai rencontré le même problème après avoir restructuré les paramètres selon les instructions du livre de Daniel Greenfield Two scoops of Django .

J'ai résolu le problème en définissant

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings.local")

dans manage.pyet wsgi.py.

Mettre à jour:

Dans la solution ci-dessus, localest le nom de fichier (settings / local.py) dans mon dossier de paramètres, qui contient les paramètres de mon environnement local.

Une autre façon de résoudre ce problème consiste à conserver tous vos paramètres courants dans settings / base.py, puis à créer 3 fichiers de paramètres distincts pour vos environnements de production, de préparation et de développement.

Votre dossier de paramètres ressemblera à ceci:

settings/
    __init__.py
    base.py
    local.py
    prod.py
    stage.py

et conservez le code suivant dans votre settings/__init__.py

from .base import *

env_name = os.getenv('ENV_NAME', 'local')

if env_name == 'prod':
    from .prod import *
elif env_name == 'stage':
    from .stage import *
else:
    from .local import *
Jinesh
la source
Pour toute personne utilisant Wagtail sur PythonAnywhere, ajoutez simplement le ".dev". à la fin de cette ligne dans WSGI ... os.environ ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings.dev' plus tard, vous devrez créer un local.py en dehors de votre dépôt source pour vos mots de passe, etc.
Inyoka
Devrait être la meilleure réponse
Dev
ImportError: Aucun module nommé local
Dheeraj M Pai
@Tessaracter utilise le nom du fichier de paramètres que vous utilisez à la place local. Dans mon cas, les paramètres locaux ont été conservés dans le fichier settings / local.py
Jinesh
1
Cela viole les conventions Django, en remplaçant le correctement documenté DJANGO_SETTINGS_MODULEpar une nouvelle variable d'environnement personnalisée qui n'est pas prise en charge par défaut et doit être traitée manuellement. Je suis surpris qu'il y ait autant de votes positifs. Je travaille sur un projet avec cette configuration et nous rencontrons beaucoup de problèmes, des difficultés de configuration d'un environnement isolé pour le développement local à la rupture des bibliothèques externes car ils s'attendent à ce que le DJANGO_SETTINGS_MODULEfonctionne comme prévu et ce n'est pas le cas.
Ariel
21

J'ai eu la même erreur avec python manage.py runserver.

Pour moi, il s'est avéré que c'était à cause d'un fichier binaire compilé (.pyc) périmé. Après avoir supprimé tous ces fichiers dans mon projet, le serveur a recommencé à fonctionner. :)

Donc, si vous obtenez cette erreur, de nulle part, c'est-à-dire sans faire aucun changement apparemment lié aux paramètres de django, cela pourrait être une bonne première mesure.

akshay
la source
2
merci pour cette astuce. J'ai eu un problème identique sur mon serveur de développement. La suppression de tous les fichiers .pyc du dossier du projet a fait l'affaire. J'étais en train de modifier le fichier settings.py juste avant que cela ne se produise.
croc
15

Supprimer les fichiers .pyc

Commande de terminal Ubuntu pour supprimer .pyc: find . -name "*.pyc" -exec rm -rf {} \;

J'ai la même erreur quand j'ai fait python manage.py runserver. C'était parce que le fichier .pyc. J'ai supprimé le fichier .pyc du répertoire du projet, puis cela fonctionnait.

Aslam Khan
la source
2
find . -type f -name *.pyc -deleteva faire
Srinivas Reddy Thatiparthy
8

Je n'avais pas spécifié le fichier de paramètres:

python manage.py runserver --settings=my_project.settings.develop
maugsburger
la source
6

Cela commence à fonctionner car sur base.py vous avez toutes les informations nécessaires dans un fichier de paramètres de base. Vous avez besoin de la ligne:

SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&amp;022shmi1jcgihb*'

Cela fonctionne donc et lorsque vous le faites from base import *, il importe SECRET_KEY dans votre fichier development.py.

Vous devez toujours importer les paramètres de base avant d'effectuer des paramètres personnalisés.


EDIT: De plus, lorsque django importe le développement de votre package, il initialise toutes les variables à l'intérieur de base depuis que vous avez défini à l' from base import *intérieur__init__.py

Guilherme David da Costa
la source
désolé, je ne comprends pas votre point. Il y avait une importation de base * au début de development.py et cela ne fonctionnait pas.
clime
Oh désolé, je suis intervenu peu importe ce qui se passait vraiment. Django essaie toujours d'importer les paramètres à partir des paramètres au lieu de votre development.py car cela semble être la raison de travailler lorsque vous importez la base à init .py
Guilherme David da Costa
5

Je pense que c'est l' erreur d'environnement , vous devriez essayer de définir:DJANGO_SETTINGS_MODULE='correctly_settings'

吾 慎行
la source
4

J'ai eu le même problème avec le céleri. Mon setting.py avant :

SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')

après:

SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', <YOUR developing key>)

Si les variables d'environnement ne sont pas définies alors: SECRET_KEY = VOTRE clé de développement

MrNinjamannn
la source
4

Dans le fichier init .py du répertoire des paramètres, écrivez l'importation correcte, comme:

from Project.settings.base import *

Pas besoin de changer wsgi.py ou manage.py

chuchotement
la source
Parfait! Merci.
Mayur
2

J'ai résolu ce problème survenant sur OS X avec Django à la fois 1.5 et 1.6 en désactivant toutes les sessions actives sur virtualenv et en le redémarrant.

andilabs
la source
2

Pour toute personne utilisant PyCharm: le bouton vert "Exécuter la configuration sélectionnée" produirait cette erreur, tout en exécutant les travaux suivants:

py manage.py runserver 127.0.0.1:8000 --settings=app_name.settings.development

Pour résoudre ce problème, vous devez modifier les variables d'environnement de la configuration. Pour ce faire, cliquez sur le menu déroulant "Sélectionner la configuration d'exécution / débogage" à gauche du bouton d'exécution vert puis cliquez sur "Modifier la configuration". Sous l'onglet "environnement", changez la variable d'environnement DJANGO_SETTINGS_MODULEen app_name.settings.development.

Jamie Williams
la source
1

Je voulais juste ajouter que j'avais cette erreur lorsque le nom de ma base de données était mal orthographié dans mon settings.pyfichier afin que la base de données ne puisse pas être créée.

Lexo
la source
1

J'ai résolu ce problème sur 1.8.4 en corrigeant les paramètres TEMPLATES qui avaient une faute de frappe (la suppression de TEMPLATES ['debug'] l'a résolu)

Passez en revue les paramètres que vous avez modifiés récemment, assurez-vous que toutes les clés sont à la lettre.

oriadam
la source
1

Pour jeter une autre solution potentielle dans le mix, j'avais un settingsdossier ainsi qu'un settings.pydans mon répertoire de projet. (Je revenais des fichiers de paramètres basés sur l'environnement à un fichier. J'ai reconsidéré depuis.)

Python commençait à ne pas savoir si je voulais importer project/settings.pyou project/settings/__init__.py. J'ai supprimé le settingsrépertoire et tout fonctionne maintenant correctement.

Brendan Quinn
la source
0

J'ai résolu ce problème en supprimant les espaces autour des signes égaux ( =) dans mon .envfichier.

aiven
la source
0

Dans mon cas, le problème était - j'avais mon app_folderet settings.pydedans. Puis j'ai décidé de faire à l' Settings folderintérieur app_folder- et cela a fait une collision avec settings.py. Je viens de renommer cela Settings folder- et tout a fonctionné.

Chiefir
la source
0

Mon Mac OS n'a pas aimé le fait qu'il ne trouve pas la variable d'environnement définie dans le fichier de paramètres:

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = os.environ.get('MY_SERVER_ENV_VAR_NAME')

mais après avoir ajouté le var env à mon environnement de développement Mac OS local, l'erreur a disparu:

export MY_SERVER_ENV_VAR_NAME ='fake dev security key that is longer than 50 characters.'

Dans mon cas, j'avais également besoin d'ajouter le --settingsparamètre:

python3 manage.py check --deploy --settings myappname.settings.production

où production.py est un fichier contenant des paramètres spécifiques à la production dans un dossier de paramètres.

Samer
la source
0

Le problème pour moi était d'appeler get_text_nooples LANGUES itérables.

En changeant

LANGUAGES = (
    ('en-gb', get_text_noop('British English')),
    ('fr', get_text_noop('French')),
)

à

from django.utils.translation import gettext_lazy as _

LANGUAGES = (
    ('en-gb', _('British English')),
    ('fr', _('French')),
)

dans le fichier des paramètres de base a résolu l' ImproperlyConfigured: The SECRET_KEY setting must not be emptyexception.

Sépia
la source
0

J'ai résolu le problème ci-dessus en commentant la ligne dans mon settings.py

SECRET_KEY=os.environ.get('SECRET_KEY')

SECRET_KEYdéclaré dans mon ~/.bashrcfichier (pour les utilisateurs Linux Ubuntu)

À des fins de développement sur ma machine locale, je n'ai pas utilisé la variable evironmnet

SECRET_KEY = '(i9b4aes#h1)m3h_8jh^duxrdh$4pu8-q5vkba2yf$ptd1lev_'

au-dessus de la ligne n'a pas donné l'erreur

Ankit Tiwari
la source
0

Dans mon cas, lors de la configuration d'une action Github, j'ai simplement oublié d'ajouter les variables env au fichier yml:

jobs:
  build:
    env:
     VAR1: 1
     VAR2: 5
Rexcirus
la source
0

La raison pour laquelle il y a tant de réponses différentes est que l'exception n'a probablement rien à voir avec SECRET_KEY. C'est probablement une exception antérieure qui est en train d'être avalée. Activez le débogage en utilisant DEBUG = True pour voir l'exception réelle.

Amit Klein
la source
0

Dans mon cas, après une longue recherche, j'ai trouvé que PyCharm dans vos paramètres Django (Paramètres> Langues et cadres> Django) avait le champ du fichier de configuration non défini. Vous devez faire en sorte que ce champ pointe vers le fichier de paramètres de votre projet. Ensuite, vous devez ouvrir les paramètres Exécuter / Déboguer et supprimer la variable d'environnement DJANGO_SETTINGS_MODULE = chemin existant.

Cela se produit car le plugin Django dans PyCharm force la configuration du framework. Il est donc inutile de configurer un os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'myapp.settings')

Thalles Rosa
la source
0

Importez base.py dans __init__.py seul. assurez-vous de ne plus répéter la même configuration !.

définir la variable d'environnement SET DJANGO_DEVELOPMENT =dev

settings/
  __init__.py
  base.py
  local.py
  production.py

Dans __init__.py

from .base import *
if os.environ.get('DJANGO_DEVELOPMENT')=='prod':
   from .production import *
else:
   from .local import *

Dans base.pyconfiguré les configurations globales. sauf pour Database. comme

SECRET_KEY, ALLOWED_HOSTS,INSTALLED_APPS,MIDDLEWARE .. etc....

Dans local.py

DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.postgresql_psycopg2',
    'NAME': 'database',
    'USER': 'postgres',
    'PASSWORD': 'password',
    'HOST': 'localhost',
    'PORT': '5432',
}
}
Ramesh Ponnusamy
la source