Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#17800 closed Uncategorized (fixed)

Empty settings.SECRET_KEY should raise an error

Reported by: Paul McMillan Owned by: nobody
Component: Core (Other) Version: 1.4-alpha-1
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

17800.patch (660 bytes) - added by Aymeric Augustin 5 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 5 years ago by 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.

Changed 5 years ago by Aymeric Augustin

Attachment: 17800.patch added

comment:2 Changed 5 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

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.

comment:3 Changed 5 years ago by Jannis Leidel

This broke the runtests.py for me.

comment:4 Changed 5 years ago by Jannis Leidel

In [17614]:

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

comment:5 Changed 5 years ago by Carl Meyer

In [17617]:

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

comment:6 Changed 5 years ago by 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.

comment:7 Changed 4 years ago by Aymeric Augustin

In [17836]:

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

This accelerated deprecation schedule was documented in r17617.

comment:8 Changed 4 years ago by Piet Delport

Reference documentation update for this change: #18759

Note: See TracTickets for help on using tickets.
Back to Top