Opened 2 years ago

Closed 2 years ago

#20181 closed Cleanup/optimization (duplicate)

auto generate SECRET_KEY file?

Reported by: michael.vogt@… Owned by: nobody
Component: Uncategorized Version: 1.5
Severity: Normal Keywords:
Cc: pegler@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I wonder if you would accept a patch that auto-generates a secret key if its not set in the settings or alternatively a new option "SECRET_KEY_AUTOGENERATE = {False,True}". It would simply check for the file "secret.txt" and load or create that using the same mechanism as what startproject is using (or used to use).

If this would be a accepted change/feature I'm happy to work on this and submit a branch

Change History (4)

comment:1 Changed 2 years ago by michael.vogt@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Essentially it would be just something like:
_secrets_file = os.path.join(os.path.dirname(file), "secret.txt")
if not os.path.exists(_secrets_file) or os.path.getsize(_secrets_file) == 0:

with open(_secrets_file, "w") as f:

# taken from django/core/management/commands/
from django.utils.crypto import get_random_string
chars = 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%&*(-_=+)'
f.write(get_random_string(50, chars))

with open(_secrets_file) as f:


del _secrets_file

comment:2 Changed 2 years ago by pegler

This idea was suggested on the django-developers mailing list a while ago (!searchin/django-developers/secret$20key$20from$20file/django-developers/KKoCec5j9mg/Kf4-_Mr07EwJ). From the discussion in that thread, it seems that the preferred method is to use multiple settings files where you store general settings in a file and then keep out of version control and have it do something like

from settings_global import *

SECRET_KEY = '.....'

I personally think that's a better approach since you're going to be overriding many settings for your various environments (dev/stage/test/prod) and not just the secret key. But I'll leave this open for others to weigh in.


comment:3 Changed 2 years ago by pegler

  • Cc pegler@… added

comment:4 Changed 2 years ago by russellm

  • Resolution set to duplicate
  • Status changed from new to closed

I'm going to mark this as a duplicate of #20081. The approach you're describing is subtly different, but the end goal (getting SECRET_KEY, and potentially other secrets, out of the range of code checkins) is the same.

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