Django: ImproperlyConfigured: параметр SECRET_KEY не должен быть пустым


102

Я пытаюсь настроить несколько файлов настроек (разработка, производство, ..), которые включают некоторые базовые настройки. Но не может. Когда я пытаюсь запустить, ./manage.py runserverя получаю следующую ошибку:

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

Вот мой модуль настроек:

(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

Базовые настройки (содержат 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'

Один из файлов настроек:

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

Код в 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)

Если я добавлю from base import *в /srv/www/cb/cb/settings/__init__.py(который в противном случае пуст), он волшебным образом начнет работать, но я не понимаю, почему. Кто-нибудь мог бы мне объяснить, что здесь происходит? Это должно быть какая-то магия модуля Python.

РЕДАКТИРОВАТЬ: все также начинает работать, если я удалю эту строку из base.py

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

Если я удалю эту строку из web.templatetags.cb_tags, она также начнет работать:

from endless_pagination.templatetags import endless

Я думаю, это потому, что, в конце концов, это приводит к

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

Таким образом, создается какой-то странный круговой материал, и игра окончена.


Собственно, в конце концов вам всегда понадобятся настройки, даже если они взяты из django.conf
Гильерме Давид да Коста

2
Попробуйте сменить DJANGO_SETTINGS_MODULE на settings.development
Гильерме Давид да Коста

Любой, кто использует virutalenvwrapper, попробует ответ Crimeminister на stackoverflow.com/questions/10738919/…
lukeaus

Ответы:


109

У меня была такая же ошибка, и это оказалось циклической зависимостью между модулем или классом, загруженным настройками, и самим модулем настроек. В моем случае это был класс промежуточного программного обеспечения, названный в настройках, который сам пытался загрузить настройки.


4
Да, я думаю, что округлость делает это.
clime

5
Выполните рефакторинг, чтобы избежать циклической зависимости. Точное решение действительно довольно специфично для вашего собственного кода.
Sam Svenbjorgchristiensensen

6
Подсказка: чтобы определить причину проблемы, например, добавьте произвольный оператор печати в файл настроек и переместите его, чтобы увидеть, где он ломается.
Felix Böhme

17
Я не нашел в этом ответа.
Avinash Raj

8
Этот ответ был бы более полезным, если бы он был более конкретным ... он говорит, что проблема в чем-то.
Hack-R

74

Я столкнулся с той же проблемой после реструктуризации настроек в соответствии с инструкциями из книги Дэниела Гринфилда « Две совки Django» .

Я решил проблему, установив

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

в manage.pyи wsgi.py.

Обновить:

В приведенном выше решении localэто имя файла (settings / local.py) в моей папке настроек, в которой хранятся настройки для моей локальной среды.

Другой способ решить эту проблему - сохранить все ваши общие настройки в settings / base.py, а затем создать 3 отдельных файла настроек для вашей производственной, промежуточной среды и среды разработки.

Ваша папка настроек будет выглядеть так:

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

и сохраните следующий код в своем 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 *

Для тех, кто использует Wagtail на PythonAnywhere, просто добавьте .dev. в конце этой строки в WSGI ... os.environ ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings.dev' позже вам нужно будет создать local.py вне вашего исходного репозитория для ваших паролей и т. д.
Inyoka

Должен быть главный ответ
Dev

ImportError: Нет модуля с именем local
Дирадж М. Пай

@Tessaracter использует имя файла настроек, который вы используете вместо local. В моем случае локальные настройки хранились в файле settings / local.py
Jinesh

2
Это нарушает соглашения Django, заменяя должным образом задокументированную DJANGO_SETTINGS_MODULEновую настраиваемую переменную среды, которая не поддерживается по умолчанию и требует ручной обработки. Я удивлен, что у него так много голосов. Я работаю над проектом с этой настройкой, и мы сталкиваемся с множеством проблем, от трудностей с настройкой изолированной среды для локальной разработки до поломки внешних библиотек, потому что они ожидают, что они DJANGO_SETTINGS_MODULEбудут работать так, как ожидалось, а это не так.
Ариэль

21

У меня была такая же ошибка с python manage.py runserver.

Для меня оказалось, что это из-за устаревшего скомпилированного двоичного (.pyc) файла. После удаления всех таких файлов в моем проекте сервер снова заработал. :)

Поэтому, если вы получаете эту ошибку из ниоткуда, то есть без каких-либо изменений, казалось бы, связанных с настройками django, это может быть хорошей первой мерой.


2
спасибо за этот совет. У меня была такая же проблема на моем сервере разработки. Удаление всех файлов .pyc из папки проекта помогло. Я редактировал файл settings.py незадолго до этого.
Croc

15

Удалить файлы .pyc

Команда терминала Ubuntu для удаления .pyc: find . -name "*.pyc" -exec rm -rf {} \;

У меня такая же ошибка, когда я запускал python manage.py runserver. Это было из-за файла .pyc. Я удалил файл .pyc из каталога проекта, тогда он работал.


3
find . -type f -name *.pyc -deleteбудет делать
Srinivas Reddy Thatiparthy

8

Я не указал файл настроек:

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

6

Он начинает работать, потому что на base.py у вас есть вся необходимая информация в файле основных настроек. Вам нужна строка:

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

Итак, он работает, и когда вы это делаете from base import *, он импортирует SECRET_KEY в ваш development.py.

Перед выполнением каких-либо пользовательских настроек всегда следует импортировать базовые настройки.


РЕДАКТИРОВАТЬ: Кроме того, когда django импортирует разработку из вашего пакета, он инициализирует все переменные внутри базы, так как вы определили from base import *внутри__init__.py


извините, я не понял вашей точки зрения. В начале development.py был from base import * in, и он не работал.
климат

Ой, извините, я прыгнул, несмотря на то, что на самом деле происходило. Django все еще пытается импортировать настройки из настроек вместо вашего development.py, поскольку кажется, что причина работы при импорте базы в init .py
Гильерме Давид да Коста

5

Я думаю, что это ошибка среды , попробуйте установить:DJANGO_SETTINGS_MODULE='correctly_settings'


4

У меня была такая же проблема с сельдереем. Мой setting.py раньше :

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

после:

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

Если переменные среды не определены, то: SECRET_KEY = ВАШ развивающий ключ


4

В init .py каталога настроек напишите правильный импорт, например:

from Project.settings.base import *

Нет необходимости изменять wsgi.py или manage.py


Отлично! Спасибо.
Mayur

3

Я решил эту проблему, возникающую в OS X с Django как 1.5, так и 1.6, деактивировав все активные сеансы в virtualenv и запустив его снова.


2

Чтобы добавить еще одно возможное решение, у меня была settingsпапка, а также settings.pyв моем каталоге проекта. (Я возвращался с файлов настроек на основе среды к одному файлу. С тех пор я пересмотрел.)

Python запутался в том, хочу ли я импортировать project/settings.pyили project/settings/__init__.py. Я удалил settingsкаталог, и теперь все работает нормально.


2

Для всех, кто использует PyCharm: зеленая кнопка «Запустить выбранную конфигурацию» вызовет эту ошибку, но при этом будут выполняться следующие действия:

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

Чтобы исправить это, вам нужно отредактировать переменные среды конфигурации. Для этого щелкните раскрывающееся меню «Выбрать конфигурацию запуска / отладки» слева от зеленой кнопки запуска, а затем щелкните «Изменить конфигурацию». На вкладке «среда» измените переменную среды DJANGO_SETTINGS_MODULEна app_name.settings.development.


1

Я просто хотел добавить, что я получил эту ошибку, когда имя моей базы данных было написано неправильно в моем settings.pyфайле, поэтому невозможно создать базу данных .


1

Я решил эту проблему в 1.8.4, исправив настройки ШАБЛОНОВ, в которых была опечатка (удаление ШАБЛОНОВ ['debug'] решило это)

Просмотрите настройки, которые вы недавно изменили, убедитесь, что все ключи под рукой.


0

Я решил эту проблему, убрав пробелы вокруг знаков равенства ( =) в моем .envфайле.


0

В моем случае проблема была - у меня было свое app_folderи settings.pyв нем. Тогда я решил сделать Settings folderизнутри app_folder- и вот сделал столкновение с settings.py. Просто переименовал Settings folder- и все заработало.


0

Моей Mac OS не понравилось, что она не нашла переменную env, установленную в файле настроек:

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

но после добавления env var в мою локальную среду разработки Mac OS ошибка исчезла:

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

В моем случае мне также нужно было добавить --settingsпараметр:

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

где production.py - это файл, содержащий производственные настройки внутри папки настроек.


0

Проблема для меня заключалась в вызове get_text_noopитерации ЯЗЫКОВ.

Изменение

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

в базовом файле настроек разрешено ImproperlyConfigured: The SECRET_KEY setting must not be emptyисключение.


0

Я решил вышеуказанную проблему, прокомментировав строку в моем settings.py

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

SECRET_KEYзаявлено в моем ~/.bashrcфайле (для пользователей Linux Ubuntu)

Для целей разработки на моем локальном компьютере я не использовал переменную evironmnet

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

строка выше не дала ошибку


0

В моем случае при настройке действия Github я просто забыл добавить переменные env в файл yml:

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

0

Причина, по которой существует так много разных ответов, заключается в том, что исключение, вероятно, не имеет ничего общего с SECRET_KEY. Вероятно, это более раннее исключение, которое проглатывается. Включите отладку с помощью DEBUG = True, чтобы увидеть реальное исключение.


0

В моем случае после долгих поисков я обнаружил, что PyCharm в ваших настройках Django (Настройки> Языки и рамки> Django) имеет неопределенное поле файла конфигурации. Вы должны указать в этом поле файл настроек вашего проекта. Затем вы должны открыть настройки Run / Debug и удалить переменную среды DJANGO_SETTINGS_MODULE = существующий путь.

Это происходит потому, что подключаемый модуль Django в PyCharm принудительно настраивает фреймворк. Поэтому нет смысла настраивать какой-либо os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'myapp.settings')


0

Импортируйте base.py в __init__.py одиночку. убедитесь, что вы больше не повторитесь с той же конфигурацией !.

установить переменную среды SET DJANGO_DEVELOPMENT =dev

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

В __init__.py

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

В base.pyнастроенных глобальных конфигурациях. кроме базы данных. лайк

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

В local.py

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

0

Я пришел сюда в поисках ответа, поскольку столкнулся с теми же проблемами, ни один из ответов здесь не помог мне. Затем, после поиска на других сайтах, я наткнулся на это простое решение. Это сработало для меня

wsgi.py

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings')

к

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings.dev')

0

Поделюсь m интересным решением!

Я поставил SECRET_KEY = "*** & ^% $ #" в файл настроек пакетов init .py и ошибка исчезла! это вообще проблема с загрузкой!

Надеюсь, это быстрое решение будет полезно для некоторых из вас!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.