Despite the HTTP client defining a custom Object#toString() and print-method, there are cases where the internal state can still be exposed in logs and other print output. This specifically happens when the client is fed into a pretty-printer (such as clj-commons/pretty) which wind up traversing the client's attributes as a record type. This is undesirable, because the auth and leases fields contain secret information which should remain private.
To address this, we can define a new Veil type which hides the data in an internal field. There's a bunch of refactoring to go with this, mostly adjusting callsites to unveil the data before using it. To simplify this, and provide a more consistent interface, several functions in the vault.auth and vault.lease namespaces have shifted to accept clients directly instead of operating on the "store" atom.
Despite the HTTP client defining a custom
Object#toString()andprint-method, there are cases where the internal state can still be exposed in logs and other print output. This specifically happens when the client is fed into a pretty-printer (such as clj-commons/pretty) which wind up traversing the client's attributes as a record type. This is undesirable, because theauthandleasesfields contain secret information which should remain private.To address this, we can define a new
Veiltype which hides the data in an internal field. There's a bunch of refactoring to go with this, mostly adjusting callsites to unveil the data before using it. To simplify this, and provide a more consistent interface, several functions in thevault.authandvault.leasenamespaces have shifted to accept clients directly instead of operating on the "store" atom.Before this change:
After: