A quick idea from the top of my head, is to change the assignment of
SECRET_KEY in the generated settings to something like:
SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY",
"insecure-<generatedvalue>")
It signals that secrets in the environment are a good idea, that the
default generated value is insecure, and it still has a random part so that
default sites aren't automatically hackable when deployed. There's no
impact to people just getting started.
We could go a small step forward and use `check --deploy` to check for the
substring `insecure` (even though I believe the KEY is technically bytes?).
Just throwing something out there.
On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
>
> Is the requirement here to avoid introduce additional barriers to getting
> up and running in local development, or to deploying a site so that it's
> accessible from the public internet?
>
> Both of these are important goals, but trading off security against the
> latter worries me. I don't think we're doing beginners any favors if we
> make it easier for them to deploy sites with security issues, especially
> since they won't be in a good position to appreciate the consequences.
> Ideally we'd make it easy for beginners to deploy sites without security
> issues, but that's a hard problem given the diversity of production
> environments; in the meantime, I think we need to accept the reality that
> figuring out how to store secrets *is* a prerequisite to deploying Django
> in production, notwithstanding how much we wish it weren't.
>
> I'd be interested in trying to contribute a solution more secure than the
> status quo without introducing more barriers to local development, if it
> would have a chance of being accepted.
>
> Taymon
>
> On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
>>
>> It's just scope:
>>
>> * Not clear we need to _replace_ the space for books, and blog posts,
>> and so on, in the main docs.
>>
>> and bandwidth:
>>
>> * These things are difficult to get right, and it needs someone to do
>> them. (PRs always warmly received!)
>>
>> On balance, I have to say, I think the default project template does very
>> well.
>> Taking a beginner, say, and adding, "As well as the million things you're
>> already dealing with, there are these things called environment variable
>> and..." is a step I'd be very cautious about taking.
>>
>> Yes, granted, for professional deployment, you might want different — but
>> we have to serve everyone.
>>
>
--
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/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com.
