Closed tarkatronic closed 8 years ago
Sure, I'd accept a pull request (with tests and docs) that supports a PGCRYPTO_KEY
key in a database config dict, which would override the use of the global PGCRYPTO_KEY
.
Would a test similar to the current test_PGCRYPTO_KEY_setting
test suffice? If not, I fear I would run into similar difficulties as occurred with building a test for #1.
Yeah, we don't need end-to-end testing for this, a test just verifying that it's finding the right key is good enough.
The actual code for this will be non-trivial, though -- both self.key
and self.base_db_type
(and the derived self.encrypt_sql
and self.decrypt_sql
) will be dependent on the connection (self.base_db_type
technically already is, but it's currently punting and assuming the default connection). A field instance isn't inherently tied to a single connection, so none of those things can be calculated in __init__
or stored as attributes on self
anymore. They'll need to become methods that take a connection and return the right value for that connection, or something similar.
Well, I've always wanted a good excuse to dive deeper into the inner mechanics of Django's database code! Thanks for the tips, I'll see what I can work out.
I am building a multi-database application, and would like to be able to use a separate encryption key per database. Would it be possible to put the key into the DATABASES setting somewhere to allow for this?