Распространение проектов Django с уникальными SECRET_KEYs

У меня есть проект Django, который я бы хотел распространять в публичном репозитории, таком как bitbucket или github. Я бы хотел, чтобы это было как можно проще установить, поэтому я включаю полный проект, а не только подключаемые приложения. Это означает, что файл settings.py также будет включен.

Как я могу избежать проблемы с settings.SECRET_KEY, которая будет одинаковой для каждой установки?

Единственное простое решение, которое пользователь может вручную изменить settings.py?

Должен ли я хранить ключ в базе данных по умолчанию и иметь settings.py инициализировать его, если он не существует? Это решило бы проблему, но мне интересно, существует ли уже стандартный способ сделать это.

Спасибо!

Ответ 1

Я бы так подумал:

Введите секретный ключ в отдельный файл "secret_key.py". Этот файл не существует для первоначальной установки. В вашем файле settings.py есть что-то вроде:

try:
    from .secret_key import SECRET_KEY
except ImportError:
    SETTINGS_DIR = os.path.abspath(os.path.dirname(__file__))
    generate_secret_key(os.path.join(SETTINGS_DIR, 'secret_key.py'))
    from .secret_key import SECRET_KEY

Функция generate_secret_key(filename), которую вы напишете, генерирует файл с именем filename (который, как мы его называем, будет secret_key.py в том же каталоге, что и settings.py), с содержимым:

SECRET_KEY = '....random string....'

Если случайная строка - это сгенерированный ключ, основанный на случайном числе.

Для генерации ключей вы можете использовать предложение Umang fooobar.com/questions/42928/....

Ответ 2

Чтобы добавить к Carles Barrobés, вы можете создать новый ключ, используя метод, который Django использует в startproject:

from django.utils.crypto import get_random_string

chars = '[email protected]#$%^&*(-_=+)'
get_random_string(50, chars)

Ответ 3

Вообще говоря, вы можете разделить конфигурацию Django на вещи, специфичные для приложения, и вещи, специфичные для сервера. Это относится к последней категории.

Существует несколько способов решения проблемы конфигурации, специфичной для сервера, она более подробно обсуждается в этом вопросе.

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

Ответ 4

Я бы решил проблему следующим образом:

Предоставьте фиктивный секретный ключ, например: I_AM_A_DUMMY_KEY_CHANGE_ME
Создайте команду управления для генерации нового: ./manage.py gen_secret_key
В документации СИЛЬНО советуем пользователям как можно скорее запустить команду

Ответ 5

В моем коде у меня есть три уровня файла настроек, вдохновленные двумя совками Django, поэтому средний выглядит так, где BASE_PRIVATE_DIR настроен в базовом шаблоне. В моем случае это из каталога django../../mysite_private, но где-то в обычных файлах под приложением git.:

from .base import *

ALLOWED_HOSTS = ['staging.django.site'] 
#Allow local override which is per deployment instance.  There should probably then be
#  an instance git for version control of the production data
try:
    import sys
    private_path = BASE_PRIVATE_DIR.child('production')
    sys.path.append(private_path)
    from private_settings import *
except ImportError:
    print(" No production overide private_settings.py found.  This is probably an error  = {}".format(private_path))
    # If it doesnt' exist that is fine and just use system and environment defaults

Ответ 6

Если вы создаете новый проект с использованием шаблона, например django-admin.py startproject --template=path_to_template project_name просто поместите {{ secret_key }} в файл настроек шаблона проекта (например, settings.py), например SECRET_KEY = '{{ secret_key }}', а Django сгенерирует его для вас.