I do have a use-case where having a default SECRET_KEY makes things much
easier - docker.
Normally you can't run management commands in a Dockerfile if there's no
secret key (and often other things) set, and usually it's best to run
collectstatic as a build step.
So your options end up being:
1. Providing a default - works well as long as you remember to change it
for production.
2. Adding ARG SECRET_KEY=x to the line before - works ok, but when you
start needing to add more env vars for various other settings, it gets
really annoying.
3. Having a specific settings file just for building the image - also
somewhat annoying.
What I usually do (perhaps unwisely) is this:
from django.core.management.utils import get_random_secret_key
SECRET_KEY = os.getenv("SECRET_KEY", get_random_secret_key())
This makes it pretty obvious (to me) if I've forgotten to set a value in an
environment because I'll keep getting logged out of the site.
That is probably a terrible experience for new users, though, I can imagine
it's pretty confusing if you don't know what the problem is.
On Fri, 26 Jun 2020 at 12:20, Shai Berger <[email protected]> wrote:
> Hello,
>
> On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
> Florian Apolloner <[email protected]> wrote:
>
> > On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 [email protected]
> > wrote:
> >
> > > Personally, I think that *at minimum* providing Django-builtin "get
> > > from env" helpers would be great; beyond that, I'd love to have
> > > them be included around `DEBUG` and `SECRET_KEY` with the current
> > > values as defaults, so they're optional. Once we see how this gets
> > > used, we can see about passing it a file instead of `os.environ`,
> > > or borrowing other ideas from any of the various supporting
> > > projects that have been suggested.
> >
> > I am all for minimal variants, but I do not think this would could
> > it. [...]
>
> > And there are plenty more things to consider; for instance I do not
> > agree that it makes sense to have "SECRET_KEY" default to a value
> > when missing in the env. It is way to easy to type "SECRT_KEY" and
> > never realize that. So if "SECRET_KEY" is taken from the environment
> > it should fail loudly if it is not present.
> >
> > [...] please note that the bar to add
> > this to Django is very high since it can (at least for things like
> > django-environ) easily live outside of Django with no realy downside.
> >
>
> Before this, when explaining the motivation for this, Kit said:
>
> > My hope is to make the smallest possible change to just start us
> > moving towards more clearly flagging, especially for newer devs,
> > "these are things that will need additional configuration in order to
> > move from 'works on my machine' to 'deployed'."
>
> We already have a tool designed for this: the "check --deploy"
> management command[1]. We can improve it a little by helping it detect
> that the SECRET_KEY is carelessly kept hard-coded from the initial
> project creation, e.g. by including somewhere a marker class:
>
> class HardCoded(str): pass
>
> and then in the default template
>
> SECRET_KEY = HardCoded('generated_value_like_today')
>
> Then the check could easily detect it and tell the user they need to
> change it.
>
> I think that a settings-only solution cannot be appropriate here, for
> the reasons Florian noted -- Kit is basically asking the default
> template to educate the user about deployment, but there is a tension
> between this and having things Just Work, which is important for
> beginners, and Just Work Securely (which is why the default SECRET_KEY
> needs to be a generated, random secret). To resolve this tension, we
> need a tool which is aware of context -- a tool which differentiates
> between the beginner on their laptop, and the novice doing their first
> deployment. The settings, in general, cannot make this distinction; a
> management command can.
>
> We have a whole bunch of documents about deployment[2] - maybe a little
> too much, and this probably encourages shorter "just do this" type
> deployment tutorials. Maybe we should make the checklist[3] more
> prominent, maybe we should make "check --deploy" even more prominent.
> But I don't think a single settings file can be all things for all
> users.
>
> My 2 cents,
> Shai.
>
>
> [1]
> https://docs.djangoproject.com/en/3.0/ref/django-admin/#cmdoption-check-deploy
> [2] https://docs.djangoproject.com/en/3.0/howto/deployment/
> [3] https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/
>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20200626131942.553c2b54.shai%40platonix.com
> .
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMYgx_XejS%2BwOdUebZbkJJccdP_Dc-YBVdW%2BbAhtxU871w%40mail.gmail.com.
