Защита Django SECRET_KEY VS возможность запуска проекта локально

Я прочитал много тем здесь о django SECRET_KEY, но большинство из них о том, как хранить его в переменной окружения вместо settings.py, на этом этапе все понятно. Сейчас я храню его в .env локально и в config var на heroku.

Я запутался в двух противоречивых моментах, которые я не могу объединить вместе.

С одной стороны, считается хорошей практикой держать SECRET_KEY в секрете. Из документации:

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

Кроме того, github греет по электронной почте, если в коде явно указан SECRET_KEY:

GitGuardian обнаружил следующий секретный ключ Django, открытый в вашей учетной записи GitHub.

С другой стороны, я хочу позволить любому человеку запускать мой проект локально. Он есть на github и развернутая версия на heroku, но это все еще демо-проект, который используется как часть портфолио, а не серьезный проект.

Какое здесь решение? Нарушить соглашение о защите и поместить его явно в settings.py?

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

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

Я использую следующий фрагмент кода:

from warnings import warn
from uuid import uuid1

def parse_bool(value):
    if not value:
        return False
    if isinstance(value, str):
        if value.isdigit():
            value = int(value)
        else:
            value = value.lower() != 'false'
    return bool(value)

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = parse_bool(os.getenv('DEBUG'))

# SECURITY WARNING: keep the secret key used in production secret!
if os.getenv('SECRET_KEY'):
    SECRET_KEY = os.getenv('SECRET_KEY')
elif DEBUG:
    SECRET_KEY = 'secret'
else:
    SECRET_KEY = str(uuid1())
    warn('Using random SECRET_KEY. '
         'Should configure it for production.')

Компромиссы таковы

  • Не-DEBUG по умолчанию означает меньшую вероятность развертывания в режиме DEBUG.
  • Читает SECRET_KEY из окружения, когда доступно.
  • В DEBUG использует жестко закодированные SECRET_KEY, чтобы сессии сохранялись при разработке.
  • Генерирует одноразовый SECRET_KEY, когда не предоставлено SECRET_KEY и не в DEBUG. Это все еще позволяет запускать код без соответствующей конфигурации и жесткого кодирования производственного ключа и должно быть достаточно безопасным, так как ключи одноразовые.

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

Вернуться на верх