Hi all,
thanks for your fast response - it seems that this is not a "ah, forget
it, boooring." theme.
I'll try to answer all (for me) relevant things at once here - sorry to
write such a huge mail.
*@Adam Johnson:*
> * A class to read django.conf.settings and add defaults/other logic
> through
Another good security improvement would be to allow the database password
and other database information to support AWS Secrets Manager, Goolge
Secrets Management, and HashiCorp vault (+ others).
I have done this in a private package used at the National Library of
Medicine, but my package is both
Taymon Beal writes:
> First-class integration with one or more secrets management systems, both
to generally contain secrets better and more specifically
> so people aren't so tempted to check SECRET_KEYs and database passwords
into source control. (I think this was mentioned in the list of GSoC
Hi Adam
Please link to the ticket here.
>
ticket: https://code.djangoproject.com/ticket/31123
PR: https://github.com/django/django/pull/12257
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
Hi Gowtham
My Django ticket was closed
>
Please link to the ticket here.
May be we can add an optional kwarg to remove_stale_contenttypes command to
> remove all contenttypes that do not have a corresponding model in existing
> appsv
>
That sounds somewhat reasonable to me. I think there are
Currently, it only removes content types in scenarios where you either
rename a model or delete a model. If I rename an App from "app_label1" to
"app_label2", it doesn't delete content types for "app_label1" and this is
causing issues where I use ContentType as a GenericForeignKey.
After I
When using settings for my third party packages I use:
* A class to read django.conf.settings and add defaults/other logic through
properties - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/conf.py
. This has the
