Эффекты изменения SECRET_KEY в Django

Поскольку этот вопрос был задан, документация по Django была изменена и теперь содержит ответ.

Секретный ключ используется для:

• Все сеансы, если вы используете какой-либо другой сеансовый бэкэнд, кроме django.contrib.sessions.backends.cache, или используете по умолчанию get_session_auth_hash().
• Все сообщения, если вы используете CookieStorage или FallbackStorage.
• Все токены PasswordResetView.
• Любое использование криптографической подписи, если не предоставлен другой ключ.

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

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

cd ~/junk # Go to some safe directory to create a new project.
django-admin startproject django_scratch
grep SECRET_KEY django_scratch/django_scratch/settings.py # copy to old project
rm -R django_scratch

Обновить

Похоже, Django добавил get_random_secret_key() в версии 1.10. Вы можете использовать это для генерации нового секретного ключа.

$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
s!)5@5s79sp=92a+!f4v!1g0d0+64ln3d$xm1f_7=749ht&-zi
$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
_)+%kymd=f^8o_fea1*yro7atz3w+5(t2/lm2cz70*e$2mn\g3
$

В соответствии с этой страницей https://docs.djangoproject.com/en/dev/topics/signing/, SECRET_KEY в основном используется для переходного материала - подписание данных, отправленных по проводу, чтобы вы могли обнаружить например, фальсификация. Похоже, что вещи, которые МОГУТ разорваться, следующие:

• Подписанные файлы cookie, например. Значения типа "запомнить мой идентификатор на этом компьютере". В этом случае cookie будет признан недействительным, подпись не сможет проверить и пользователь должен будет повторно аутентифицироваться.
• Для всех пользователей, которые запросили ссылки для пароля reset или загрузки пользовательского файла, эти ссылки больше не будут действительны. Пользователям просто нужно будет повторно запросить эти ссылки.

Кто-то с более недавним и/или значительным опытом Django, чем я, мог бы перезвонить в противном случае, но я подозреваю, что, если вы явно не делаете что-то с подписывающим API, это должно только создать неудобство для ваших пользователей.

Строка SECRET_KEY в основном используется для шифрования и/или хэширования данных cookie. Множество фреймворков (в том числе Django) приходит к этому, поскольку файлы cookie по умолчанию имеют свои собственные недостатки.

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

Конечно, это тривиальный пример, но именно так используется SECRET_KEY.

Django является внутренним, используя его, например, для {% csrf_token%} и еще нескольких вещей. Это действительно не должно влиять на ваше приложение, если вы измените его на основе вашего вопроса и что вы его не используете.

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