Django: ImproperlyConfigured: Параметр SECRET_KEY не повинен бути порожнім


101

Я намагаюся створити кілька файлів налаштувань (розробка, виробництво, ..), які містять деякі базові налаштування. Не вдається досягти успіху. Коли я намагаюся запустити, ./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.

EDIT: Все також починає працювати, якщо я видалю цей рядок з 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
Guilherme David da Costa

2
Спробуйте змінити свій DJANGO_SETTINGS_MODULE на settings.development
Guilherme David da Costa

Будь-яке використання virutalenvwrapper відповіді спробувати crimeminister за адресою stackoverflow.com/questions/10738919 / ...
lukeaus

Відповіді:


107

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


4
Так, я думаю, що циркулярність це робить.
clime

5
Рефактор, щоб уникнути кругової залежності. Точне рішення насправді досить специфічне для вашого власного коду.
Sam Svenbjorgchristiensensen

6
Підказка: для того, щоб визначити, що спричиняє проблему, наприклад, додайте оператор випадкового друку у файл налаштувань та перемістіть його, щоб побачити, де він зламався.
Фелікс Беме

14
Я не знайшов відповіді на це.
Avinash Raj

8
Ця відповідь була б кориснішою, якби вона була більш конкретною ... в ній сказано, що проблема в "чомусь".
Hack-R

73

Після реструктуризації налаштувань я зіткнувся з тією ж проблемою згідно з інструкціями книги Даніеля Грінфілда " Два совки Джанго" .

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

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

@Tessaracter використовує ім'я файлу налаштувань, який ви використовуєте замість local. У моєму випадку локальні налаштування зберігались у файлі settings / local.py
Jinesh

1
Це порушує конвенції Django, замінюючи належним чином задокументовану DJANGO_SETTINGS_MODULEнову користувальницьку змінну середовища, яка не підтримується нестандартно і з нею слід обробляти вручну. Я здивований, що у нас так багато голосів. Я працюю над проектом із цим налаштуванням, і ми стикаємося з багатьма проблемами, починаючи від труднощів у налаштуванні ізольованого середовища для локальної розробки і закінчуючи руйнуванням зовнішніх бібліотек, оскільки вони очікують, що вони DJANGO_SETTINGS_MODULEпрацюватимуть належним чином, а це не так.
Аріель

20

У мене була та ж помилка з 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 з каталогу проекту, тоді він працював.


2
find . -type f -name *.pyc -deleteзробить
Срінівас Редді Татіпарті


6

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

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

Отже, це працює, і коли ви це робите from base import *, він імпортує SECRET_KEY у ваш development.py.

Завжди слід імпортувати основні налаштування, перш ніж робити будь-які власні налаштування.


EDIT: Також, коли django імпортує розробку з вашого пакету, він ініціалізує всі змінні всередині бази, оскільки ви визначили from base import *всередині__init__.py


вибачте, я не розумію вашої думки. На початку development.py був базовий імпорт *, і він не працював.
clime

О, вибачте, я заскочив незалежно від того, що насправді відбувалося. Django все ще намагається імпортувати налаштування з налаштувань замість вашого development.py, оскільки це здається причиною роботи під час імпорту бази в init .py
Guilherme David da Costa

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

2

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


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, виправивши налаштування ШАБЛОНІВ, які мали друкарську помилку (видалення ШАБЛОНІВ ['налагодження'] вирішило)

Перегляньте параметри, які ви нещодавно змінили, переконайтесь, що всі клавіші є додатковими.


1

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

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


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)

З метою розробки на моєму localmachine я не використовував змінну 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) поле конфігураційного файлу не визначено. Ви повинні вказати це поле на файл налаштувань вашого проекту. Потім потрібно відкрити налаштування Запуск / Налагодження та видалити змінну середовища 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',
}
}
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.