On Friday, June 26, 2020 at 12:11:34 PM UTC+2 re...@fleschenberg.net wrote:

> There is a trade-off between security and development convenience here. 
> At the moment, the settings generated by manage.py startproject are 
> geared towards development (random default value for SECRET_KEY, DEBUG = 
> False).


Yes, but the situation is somewhat different in that case; for instance we 
advice people often to have different settings files ala dev.py and 
prod.py. Now dev.py can happily define `SECRET_KEY=123`, not much of an 
issue there. prod.py would simply use `SECRET_KEY = 
os.environ["SCRET_KEY"]` without a default since you absolutely need to set 
that. It becomes dangerous when you go full 12-factor and merge those two 
config files. Now it might become (as you suggested) `SECRET_KEY = 
os.environ.get("SECRET_KEY", "123")` which I find rather dangerous. The 
better solution here might be to use a random default (ie every process 
start) but that might make development tedious.

So all in all I think the chance of misstyping `SECRET_KEY` is higher than 
setting `DJANGO_SETTINGS_MODULE`  to dev in production… FWIW this is 
exactly the reason why I also still have dev & prod settings. They both 
star-import stuff from settings.common, but otherwise define whatever they 
need. This also allows me to keep settings files free from if/else 
conditionals, since a production deployment usually is vastly different 
from a dev variant (error logging to sentry, x-forwarded-for handling, 
secure cookies everyhwere).
 

> There is also manage.py check --deploy. This catches DEBUG = True, but 
> not SECRET_KEY. Would it be a good idea to prefix the default SECRET_KEY 
> with something like "insecure-" and check for that in manage.py check 
> --deploy? 
>

Oh wow, this is good. I'd even go further and call it "dj::insecure::" so 
you can really easily grep for it and maybe even add it to git hooks.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b67b2014-a060-4205-a5b0-e64fd78f79abn%40googlegroups.com.
  • ... Tom Forbes
  • ... Bobby Mozumder
  • ... Javier Buzzi
  • ... Carsten Fuchs
  • ... Javier Buzzi
  • ... Florian Apolloner
  • ... Javier Buzzi
  • ... Adam Johnson
  • ... René Fleschenberg
  • ... René Fleschenberg
  • ... Florian Apolloner
  • ... Shai Berger
  • ... Tom Carrick
  • ... Florian Apolloner
  • ... Adam Johnson
  • ... Tim Graham
  • ... Florian Apolloner
  • ... Florian Apolloner
  • ... Carlton Gibson
  • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)
  • ... 'Aaron C. de Bruyn' via Django developers (Contributions to Django itself)

Reply via email to