Django: ImproperlyConfigured: l'impostazione SECRET_KEY non deve essere vuota


101

Sto cercando di configurare più file di impostazione (sviluppo, produzione, ..) che includono alcune impostazioni di base. Non ci riesco però. Quando provo a eseguire, ./manage.py runserverricevo il seguente errore:

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

Ecco il mio modulo delle impostazioni:

(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

Impostazioni di base (contiene 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', 'clime7@gmail.com'),
)

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'

Uno dei file di impostazione:

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

Codice in 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)

Se aggiungo from base import *in /srv/www/cb/cb/settings/__init__.py(che altrimenti è vuoto), inizia magicamente a funzionare ma non capisco perché. Qualcuno potrebbe spiegarmi cosa sta succedendo qui? Deve essere una magia del modulo Python.

EDIT: Tutto inizia a funzionare anche se rimuovo questa riga da base.py

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

Se rimuovo questa riga da web.templatetags.cb_tags, inizia a funzionare anche:

from endless_pagination.templatetags import endless

Immagino sia perché, alla fine, porta a

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

Quindi crea alcune strane cose circolari e il gioco finisce.


Esatto, alla fine avrai sempre bisogno delle impostazioni, anche se proviene da django.conf
Guilherme David da Costa

2
Prova a cambiare il tuo DJANGO_SETTINGS_MODULE in settings.development
Guilherme David da Costa

Chiunque utilizzi virutalenvwrapper risposta meta di crimeminister a stackoverflow.com/questions/10738919/...
lukeaus

Risposte:


107

Ho avuto lo stesso errore e si è rivelata una dipendenza circolare tra un modulo o una classe caricata dalle impostazioni e il modulo delle impostazioni stesso. Nel mio caso si trattava di una classe middleware che è stata nominata nelle impostazioni che a sua volta ha cercato di caricare le impostazioni.


4
Sì, penso che la circolarità lo faccia.
clima

5
Refactoring per evitare la dipendenza circolare. La soluzione esatta è abbastanza specifica per il tuo codice.
Sam Svenbjorgchristiensensen

6
Suggerimento: per identificare la causa del problema, ad esempio aggiungi un'istruzione di stampa casuale nel file delle impostazioni e spostala per vedere dove si interrompe.
Felix Böhme,

16
Non ho trovato una risposta con questo.
Avinash Raj

8
Questa risposta sarebbe più utile se fosse più specifica ... dice che il problema è "qualcosa".
Hack-R

73

Mi sono imbattuto nello stesso problema dopo aver ristrutturato le impostazioni secondo le istruzioni del libro Two scoops of Django di Daniel Greenfield .

Ho risolto il problema impostando

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

in manage.pye wsgi.py.

Aggiornare:

Nella soluzione di cui sopra, localè il nome del file (settings / local.py) all'interno della mia cartella delle impostazioni, che contiene le impostazioni per il mio ambiente locale.

Un altro modo per risolvere questo problema è mantenere tutte le impostazioni comuni all'interno di settings / base.py e quindi creare 3 file di impostazioni separati per gli ambienti di produzione, gestione temporanea e sviluppo.

La tua cartella delle impostazioni sarà simile a:

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

e mantieni il codice seguente nel tuo file 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 *

Per chiunque utilizzi Wagtail su PythonAnywhere, è sufficiente aggiungere ".dev". alla fine di questa riga in WSGI ... os.environ ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings.dev' in seguito dovrai creare un local.py al di fuori del repository sorgente per le tue password ecc.
Inyoka

Dovrebbe essere la risposta migliore
Dev

ImportError: Nessun modulo denominato local
Dheeraj M Pai

@Tessaracter usa il nome del file delle impostazioni che usi invece di local. Nel mio caso, le impostazioni locali sono state mantenute nel file settings / local.py
Jinesh,

1
Ciò viola le convenzioni di Django, sostituendo quella adeguatamente documentata DJANGO_SETTINGS_MODULEcon una nuova variabile di ambiente personalizzata che non è supportata immediatamente e deve essere gestita manualmente. Sono sorpreso che questo abbia così tanti voti positivi. Sto lavorando a un progetto con questa configurazione e stiamo riscontrando molti problemi, dalle difficoltà nella configurazione di un ambiente isolato per lo sviluppo locale alla rottura di librerie esterne perché si aspettano DJANGO_SETTINGS_MODULEche funzioni come previsto e non è così.
Ariel

21

Ho avuto lo stesso errore con python manage.py runserver .

Per me, si è scoperto che era a causa di un file binario compilato (.pyc) non aggiornato. Dopo aver eliminato tutti questi file nel mio progetto, il server ha iniziato a funzionare di nuovo. :)

Quindi, se ottieni questo errore, dal nulla, cioè senza apportare alcuna modifica apparentemente correlata alle impostazioni di django, questa potrebbe essere una buona prima misura.


2
grazie per questo suggerimento. Ho avuto un problema identico sul mio server di sviluppo. L'eliminazione di tutti i file .pyc dalla cartella del progetto ha funzionato. Stavo modificando il file settings.py appena prima che ciò accadesse.
croc

15

Rimuovi i file .pyc

Comando del terminale Ubuntu per l'eliminazione di .pyc: find . -name "*.pyc" -exec rm -rf {} \;

Ho lo stesso errore quando ho eseguito Python manage.py runserver. È stato perché il file .pyc. Ho cancellato il file .pyc dalla directory del progetto, quindi funzionava.


2
find . -type f -name *.pyc -deletefarà
Srinivas Reddy Thatiparthy

8

Non avevo specificato il file delle impostazioni:

python manage.py runserver --settings=my_project.settings.develop

6

Inizia a funzionare perché su base.py hai tutte le informazioni necessarie in un file delle impostazioni di base. Hai bisogno della linea:

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

Quindi funziona e quando lo fai from base import *, importa SECRET_KEY nel tuo file development.py.

È sempre necessario importare le impostazioni di base prima di eseguire qualsiasi impostazione personalizzata.


EDIT: Inoltre, quando django importa lo sviluppo dal tuo pacchetto, inizializza tutte le variabili all'interno di base da quando hai definito from base import *all'interno__init__.py


scusa, non ho capito il tuo punto. C'era dalla base import * in all'inizio di development.py e non funzionava.
clima

Oh scusa, sono saltato dentro indipendentemente da quello che stava realmente accadendo. Django sta ancora cercando di importare le impostazioni dalle impostazioni anziché dal tuo development.py poiché sembra il motivo del lavoro quando importi la base su init .py
Guilherme David da Costa

5

Penso che sia l' errore di ambiente , dovresti provare a impostare:DJANGO_SETTINGS_MODULE='correctly_settings'


4

Ho avuto lo stesso problema con il sedano. Il mio setting.py prima :

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

dopo:

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

Se le variabili d'ambiente non sono definite allora: SECRET_KEY = LA TUA chiave di sviluppo


4

Nel init .py della directory impostazioni scrivere l'importazione corretta, come:

from Project.settings.base import *

Non è necessario modificare wsgi.py o manage.py


Perfetto! Grazie.
Mayur

2

Ho risolto questo problema che si verificava su OS X con Django sia 1.5 che 1.6 disattivando tutte le sessioni attive su virtualenv e riavviandolo.


2

Per chiunque utilizzi PyCharm: il pulsante verde "Esegui configurazione selezionata" produrrebbe questo errore, ma eseguendo i seguenti lavori:

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

Per risolvere questo problema è necessario modificare le variabili di ambiente della configurazione. A tale scopo, fare clic sul menu a discesa "Seleziona configurazione di esecuzione / debug" a sinistra del pulsante verde di esecuzione e quindi fare clic su "modifica configurazione". Nella scheda "ambiente" cambia la variabile di ambiente DJANGO_SETTINGS_MODULEin app_name.settings.development.


1

Volevo solo aggiungere che ho ricevuto questo errore quando il nome del mio database è stato scritto in modo errato nel mio settings.pyfile, quindi non è stato possibile creare il DB.


1

Ho risolto questo problema su 1.8.4 correggendo le impostazioni di TEMPLATES che avevano un errore di battitura (la rimozione di TEMPLATES ['debug'] lo ha risolto)

Controlla le impostazioni che hai modificato di recente, assicurati che tutte le chiavi siano come da manuale.


1

Per aggiungere un'altra potenziale soluzione al mix, avevo una settingscartella e un filesettings.py nel mio progetto. (Stavo tornando dai file delle impostazioni basate sull'ambiente a un file. Da allora ho riconsiderato.)

Python si stava confondendo sul fatto che volessi importare project/settings.py o project/settings/__init__.py. Ho rimosso la settingsdirectory e ora tutto funziona correttamente.


0

Ho risolto questo problema rimuovendo gli spazi attorno ai segni di uguale ( =) nel mio .envfile.


0

Nel mio caso il problema era: avevo il mio app_foldere settings.pydentro. Poi ho deciso di fare l' Settings folderinterno app_folder- e questo ha fatto una collisione con settings.py. L'ho appena rinominato Settings foldere tutto ha funzionato.


0

Al mio Mac OS non piaceva il fatto che non avesse trovato la variabile env impostata nel file delle impostazioni:

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

ma dopo aver aggiunto env var al mio ambiente di sviluppo Mac OS locale, l'errore è scomparso:

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

Nel mio caso, avevo anche bisogno di aggiungere il --settingsparametro:

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

dove production.py è un file contenente le impostazioni specifiche della produzione all'interno di una cartella delle impostazioni.


0

Il problema per me era chiamare get_text_noopl'iterabile LANGUAGES.

Mutevole

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

per

from django.utils.translation import gettext_lazy as _

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

nel file delle impostazioni di base ha risolto l' ImproperlyConfigured: The SECRET_KEY setting must not be emptyeccezione.


0

Ho risolto il problema precedente commentando la riga nel mio settings.py

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

SECRET_KEY dichiarato nel mio ~/.bashrc file (per utenti Linux Ubuntu)

Per scopi di sviluppo sulla mia macchina locale non ho usato la variabile evironmnet

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

sopra la riga non ha dato l'errore


0

Nel mio caso, durante l'impostazione di un'azione Github mi sono semplicemente dimenticato di aggiungere le variabili env al file yml:

jobs:
  build:
    env:
     VAR1: 1
     VAR2: 5

0

Il motivo per cui ci sono così tante risposte diverse è perché l'eccezione probabilmente non ha nulla a che fare con SECRET_KEY. Probabilmente è un'eccezione precedente che viene inghiottita. Attiva il debug usando DEBUG = True per vedere la vera eccezione.


0

Nel mio caso, dopo una lunga ricerca ho scoperto che PyCharm nelle impostazioni di Django (Impostazioni> Lingue e framework> Django) aveva il campo del file di configurazione non definito. Dovresti fare in modo che questo campo punti al file delle impostazioni del tuo progetto. Quindi, è necessario aprire le impostazioni di esecuzione / debug e rimuovere la variabile di ambiente DJANGO_SETTINGS_MODULE = percorso esistente.

Ciò accade perché il plugin Django in PyCharm forza la configurazione del framework. Quindi non ha senso configurare alcun os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'myapp.settings')


0

Importa base.py in __init__.py da solo. assicurati di non ripetere più la stessa configurazione !.

imposta la variabile d'ambiente SET DJANGO_DEVELOPMENT =dev

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

Nel __init__.py

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

In base.pyconfigurato le configurazioni globali. ad eccezione di Database. piace

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

Nel local.py

DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.postgresql_psycopg2',
    'NAME': 'database',
    'USER': 'postgres',
    'PASSWORD': 'password',
    'HOST': 'localhost',
    'PORT': '5432',
}
}
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.