Re: Making startproject's settings more 12-factor-y
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 wrote:
> Hello,
>
> On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
> Florian Apolloner wrote:
>
> > On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> > 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 django-developers+unsubscr...@googlegroups.com.
> 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
Re: Making startproject's settings more 12-factor-y
Hello,
On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
Florian Apolloner wrote:
> On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> 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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20200626131942.553c2b54.shai%40platonix.com.
Re: Making startproject's settings more 12-factor-y
Hi, On 6/26/20 12:11 PM, René Fleschenberg wrote: > geared towards development (random default value for SECRET_KEY, DEBUG = > False). I meant DEBUG = True here, of course :) -- René Fleschenberg -- 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/38989a0b-6d61-9317-40f3-588a2bd1c359%40fleschenberg.net.
Re: Making startproject's settings more 12-factor-y
Hi Flo, > 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. "DEBUG" is in a similar category there > but could default to False to be safe. 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). Personally, I like to keep that convenience, so I do SECRET_KEY = os.environ.get(SECRET_KEY, original_default_value) 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? > I personally rather have no solution in Django itself before forcing a > half-baked one down everyone. Also 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. +1 -- René Fleschenberg -- 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/e10f9b32-41af-5cd1-a55d-8b8a9adf4f59%40fleschenberg.net.
Re: Making startproject's settings more 12-factor-y
>
> i dont belive in adding default names to environment variables, they're up
> to the user to define
>
Javier, I think you missed what Florian was talking about. He was
suggesting there shouldn't be default *values* for some settings.
> I personally rather have no solution in Django itself before forcing a
> half-baked one down everyone. Also 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.
I agree with this sentiment. The proliferation of libraries can be a bit
confusing, but I've not yet felt one solution was "the winner".
Using environment variables isn't even suitable for all situations. They
make sense for managed platforms like Heroku, or single process servers.
But on shared servers, they can be a security risk because other users can
potentially read them from the process:
https://www.diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
. This is why Docker has a system for providing managed secrets through a
filesystem mount: https://docs.docker.com/engine/swarm/secrets/ .
On Fri, 26 Jun 2020 at 09:55, Javier Buzzi wrote:
> Hi Florian, thank for your input, i dont belive in adding default names to
> environment variables, they're up to the user to define. Nothing will be
> given by default, you need the SECRET_KEY? `from_env` has no idea what that
> means, its just another name, so you tell it what it will do with this such
> as `from_env.str("SECRET_KEY")` or simply `from_env("SECRET_KEY")` if its a
> string. But if "SECRET_KEY" is taken by some other process and you need to
> add another one to be your SECRET_KEY for django and you call it "FOO" then
> `FOO` would be the name you pass to `from_env` and assign it to your
> SECRET_KEY = from_env('FOO'). Trying to really nail the point home: there
> are NO default environment names (other than DJANGO_SETTINGS_MODULE but
> that has nothing to do with this).
>
> - Buzzi
>
> --
> 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/d6cf479b-4e37-411b-b999-73a5944995a3o%40googlegroups.com
>
> .
>
--
Adam
--
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/CAMyDDM09srqq-Tm3cKJvZ1m_Q6i3wOdoHANd8d%2BjWQd-%3DeD%3DpA%40mail.gmail.com.
Re: Making startproject's settings more 12-factor-y
Hi Florian, thank for your input, i dont belive in adding default names to
environment variables, they're up to the user to define. Nothing will be
given by default, you need the SECRET_KEY? `from_env` has no idea what that
means, its just another name, so you tell it what it will do with this such
as `from_env.str("SECRET_KEY")` or simply `from_env("SECRET_KEY")` if its a
string. But if "SECRET_KEY" is taken by some other process and you need to
add another one to be your SECRET_KEY for django and you call it "FOO" then
`FOO` would be the name you pass to `from_env` and assign it to your
SECRET_KEY = from_env('FOO'). Trying to really nail the point home: there
are NO default environment names (other than DJANGO_SETTINGS_MODULE but
that has nothing to do with this).
- Buzzi
--
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/d6cf479b-4e37-411b-b999-73a5944995a3o%40googlegroups.com.
Re: Making startproject's settings more 12-factor-y
Hi there,
On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com 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. your
"get from env" helpers would basically be os.environ.get("SECRET_KEY",
"secret_default") which does provide much usefulness on it's own imo. So
even if we started out with a minimal implementation we'd at least have to
have a good plan on what to do in the future.
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. "DEBUG" is in a similar category there but could default to
False to be safe.
I personally rather have no solution in Django itself before forcing a
half-baked one down everyone. Also 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.
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/68e6a5e0-ea75-43e9-b34a-24f18ced73d4n%40googlegroups.com.
Re: Making startproject's settings more 12-factor-y
Hi Carsten, great question! The idea as i see it is: having the least amount of moving parts the better. The trick here is unification, keep a single settings file with 99% of the configuration needed using environment variables/secrets/zookeeper/etc to swap out environment specific options (activate debug mode? database connections, cache connections, domain_allowlist (formally whitelist), etc.) This has happened a couple of times in my lifetime, stop me if you've heard it: You have N environments, they're all slightly different, you're working on local and some kind of qa environment, everything is going great, but you forgot to do that last minute change you did on the higher environments to the prod settings -- you deployed; deployment failed. Sound familiar? Having a single / or at least keeping the amount of environment setting files to a minimum will greatly benefit you in the long run, its also easier to test: remember flat is better than nested. With the method i'm suggesting, your example would not need a localconfig.py since settings.py would just import them from the environment variables. - Buzzi -- 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/0047aea4-d07d-4559-b613-b3ab1976a9f9o%40googlegroups.com.
Re: Making startproject's settings more 12-factor-y
Hello, Am 25.06.20 um 19:51 schrieb Kit La Touche: > […] Once we see how this gets used, we can see about passing it a file > instead of `os.environ`, […] This is probably a stupid question, but what is the advantage of this (and env vars) over this: In project_dir/project_dir: settings.py localconfig.example localconfig.py settings.py is the normal settings file. localconfig.example is an example file for a local configuration, kept in version control. localconfig.py is a customized copy of localconfig.example, not kept in version control. localconfig.example and localconfig.py would contain e.g.: DEBUG = False SECRET_KEY = '1234' # ... and in settings.py: from project_dir import localconfig DEBUG = localconfig.DEBUG SECRET_KEY = localconfig.SECRET_KEY ? Best regards, Carsten -- 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/ce46b909-957f-4e7c-15e0-24d14492a195%40cafu.de.
