Opened 6 years ago

Last modified 6 years ago

#30178 closed Bug

Support duck-typing for database passwords in settings — at Version 1

Reported by: Dan Davis Owned by: Dan Davis
Component: Database layer (models, ORM) Version: 2.1
Severity: Normal Keywords: oracle
Cc: Mariusz Felisiak Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Dan Davis)

I have a curious use-case where, as a U.S. Federal Agency, we've built a rather complete mechanism to avoid having database passwords in our settings files. We have a common library that allows us to "get a password", which returns an object which is duck-typed to a string. When str is called, it obtains the password (or uses a cached copy of the password) using a network protocol, and that returns that.

We are mostly an Oracle shop. We are now looking at upgrading to Django 2.2 which will be LTS, and have formerly been on Django 1.11 which has been LTS.

It appears that ticket #29199, aka https://github.com/django/django/commit/acfc650f2a6e4a79e80237eabfa923ea3a05d709, broke that for us.

My organization would love to see this lack of duck-typing as a bug; rather than treating this as a request for all passwords to be pluggable (e.g. a Callable). Supporting duck-typing is consistent with backwards compatibility and also with Python philosophy.

I will attempt to provide a test case and a fix. Separately from this ticket, I'll check the other backends, as some users do use postgresql, MySQL, etc. even if it is not the norm.

Change History (1)

comment:1 by Dan Davis, 6 years ago

Description: modified (diff)
Summary: Support duct-typed database passwords in settingsSupport duck-typing for database passwords in settings
Note: See TracTickets for help on using tickets.
Back to Top