Thanks for the discussion all, and PRs. Lots of different perspectives. * Florian's draft PR looks more or less right, so we should be able to eliminate the need to specify a SECRET_KEY if you're not going to use it. * I opened #31757 <https://code.djangoproject.com/ticket/31757> to capture the idea to add a prefix (say `dj::insecure`) to the generated SECREY_KEY, and a deployment system check to guard against using that.
Then (summarising): * There was a similar discussion to here, and PR, on #20081 <https://code.djangoproject.com/ticket/20081#comment:23>. The same kind of points against favouring env vars were raised by Django Security Team members as have been raised on this ticket. (It's an approach but not the only one.) * There is a difficulty for beginners coming to deployment. (Not just beginners, let's be honest 🙂). Most likely way forward is better guides to different options, either in the Django docs, or in blog posts, or beginning in one and moving to the other. The current Deployment Docs <https://docs.djangoproject.com/en/3.0/howto/deployment/> are maybe not as good as we'd like: but it's hard, and hard to keep up to date if they become too specific, and there is a steady stream of material out there that covers this — Maybe the highest ROI is a group working there. * There are great third-party packages out there addressing the problems here. That there's no clear winner is probably in part because there are multiple ways of doing it, that are all good in some circumstance. We shouldn't try to narrow that artificially. I suspect this will come up again. 🙂 Kind Regards, Carlton -- 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/ed138a33-9b88-44ef-b305-ab28e738515fo%40googlegroups.com.
