The number of default-generated SECRET_KEYs that can be found publicly on
GitHub alone suggests to me that no, the existence of that page is not
sufficient to protect users from making this mistake.
Deploying to production already requires worrying about things more
complicated than a SECRET_KEY,
There is such a link since 2013:
https://github.com/django/django/commit/912b5d2a6bc78067d6a7e130f10514c51bd1a58f
On Thu, 24 Oct 2019 at 23:31, Olivier Dalang
wrote:
> Hi,
>
> Just a reminder about this page in the docs:
> https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
> It
Hi,
Just a reminder about this page in the docs:
https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
It basically already covers it all. Maybe a direct link to that page from
the settings file would be good enough?
Cheers,
Olivier
On Thu, Oct 24, 2019, 04:45 Josh Smeaton wrote:
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-")
It signals that secrets in the environment are a good idea, that the
default generated value is insecure,
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
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
Exactly, I believe a best practices section should be added to the already
robust Django documentation. Something akin to the Two Scoops of Django
book. That would be better than focusing a pattern on everyone.
On Fri, 11 Oct 2019, 13:21 Carlton Gibson, wrote:
> I can see a How-To explaining
I can see a How-To explaining different patterns here being a valid addition to
the docs.
FWIW, there’s a PR to ease/enable SECRET_KEY rotation. It might mitigate some
of the issues with first committing sensitive values to git when it lands.
https://code.djangoproject.com/ticket/30360
--
This feature should be filled under a "nice to have" and not a "must have".
On Fri, 11 Oct 2019, 12:45 Mariusz Felisiak,
wrote:
> Hi,
>
> I don't agree that Django should force pattern with multiple settings
> files (*base, development, staging, and production*) there is many ways
> to keep
Hi,
I don't agree that Django should force pattern with multiple settings
files (*base, development, staging, and production*) there is many ways to
keep secrets and probably a *production.py* settings file is not the best
one (IMO). Everything depends on a project (not all of them have
On Thursday, October 10, 2019 at 9:41:53 PM UTC+2, Bobby Mozumder wrote:
>
> Additionally, startproject should add a .gitignore in the root directory
> to not include development/staging/production settings files.
>
I am very much against creating a .gitignore as part of startproject. Also
I
I strongly disagree with this.
I've not seen a common standard between companies when it comes to settings
in Django and for good reason. Different companies employ different
standards and practices when it comes to configuration and security.
Enforcing an arbitrary standard - such as a settings
Hi, may I disagree - I set up projects very often (for testing a
package), and I always feel a bit awkward because of that monolithic
settings.py file.
I can really support Bobby's idea, even if
development/staging/production may be a bit overkill. Having a practical
standard which ensures good
Hello Bobby,
I think this should be added to a best practises documentation and not
codified in Django. As I feel that would be overkill.
On Thu, 10 Oct 2019, 20:41 Bobby Mozumder, wrote:
> In particular, they include settings that shouldn’t be stored in a git
> repo such as SECRET_KEY and
14 matches
Mail list logo
