Closed sloria closed 3 years ago
Hold on this until https://github.com/encode/starlette/issues/301 is resolved.
Excellent work on this lib. Seems that this issue is "resolved" in your PR encode/starlette#303
Thanks, I'm aware. I'll have to give this more thought. I think if we add this to environs, we'll go with the .value
approach suggested in https://github.com/encode/starlette/issues/301.
Feedback welcome!
An alternative to env.secret
would be to allow any casted value to be secret.
SECRET_BOOL = env.bool('MY_PRECIOUS', secret=True)
print(SECRET_BOOL) # => "*******"
print(SECRET_BOOL.value) # => True
Related to this, it would be nice to be able to store encrypted values which would then be automatically decrypted by the library when needed and up to a previously specified master password. Something similar to http://www.jasypt.org/encrypting-configuration.html in Java.
To be identified such values would be surrounded by ENC(...)
for instance. As a rule of thumb passwords should never be checked-in. But with such a mechanism, this is then acceptable.
Currently I am working with a custom parser to handle such cases.
Encryption seems outside the scope of environs. environs is used for parsing values that are not checked into source control. If you do need encryption you can do so after parsing, e.g.
PASSWORD = decrypt(env.str('PASSWORD'))
Or use a custom parser that handles your specific encryption:
@env.parser_for('encrypted')
def encrypted_value(value):
return decrypt(value)
password = env.encrypted('PASSWORD')
A custom parser also works but doesn't allow composition.
Closing for lack of interest
For casting strings that shouldn't be revealed in tracebacks, etc.
See https://github.com/encode/starlette/blob/1e1f3bab464d497a9250590a72b025f6095b20a7/starlette/datastructures.py#L179