Empty settings.SECRET_KEY should raise an error

[Paul McMillan]

Django does not complain if the SECRET_KEY is left to the default value. It should at least raise a warning, and (imho) should really raise an error.

If we do allow Django to run with an empty secret key, we should raise an error if an attempt is made to use cookie-based sessions.

[Aymeric Augustin]

django.conf.default_settings says:

# A secret key for this particular Django installation. Used in secret-key
# hashing algorithms. Set this in your settings, or Django will complain
# loudly.
SECRET_KEY = ''

However, no check was added to match this comment in r230.

[Aymeric Augustin]

In [17611]:

Fixed #17800 -- Prevented Django from starting without a SECRET_KEY, since that opens a variety of security problems. Thanks PaulM for the report.

[Jannis Leidel]

This broke the runtests.py for me.

[Jannis Leidel]

In [17614]:

Added a default SECRET_KEY setting to the default test sesttings (refs #17800).

[Carl Meyer]

In [17617]:

Refs #17800 - Added release notes and deprecation note about SECRET_KEY requirement.

[Carl Meyer]

Paul and I discussed this further and felt that raising an exception on an empty SECRET_KEY, while ideally preferable, is too backwards-incompatible to be introduced at this post-beta stage of the release cycle. We decided to instead make it a DeprecationWarning for 1.4 and elevate to an exception in 1.5; an accelerated deprecation schedule, but avoiding breaking things in an RC. Paul implemented this decision in r17616 and I documented it in r17617.

[Aymeric Augustin]

In [17836]:

Prevented Django from running with an empty secret key. Refs #17800.

This accelerated deprecation schedule was documented in r17617.

[Pi Delport]

Reference documentation update for this change: #18759