Open rimitchell opened 4 years ago
👍 we too are running into this issue
On the other hand, consider the different usage patterns of this library and the CLI. While the CLI is called on the command line relatively rare, it is allowed to amplify the amount of ReST requests it makes to access a KV2 object. For a library used by some application, which probably does requests at a high rate (possibly deployed in many instances), it is highly unfavourable to double the amount of requests it makes to a KV2, just to find out the prefix length every time.
In a lot of scenarios a user of this library may not have access to update permissions to be able to read the
/v1/sys/mounts
path and or it may be included in other libraries which do not expose either the engine version or the path prefix depth functionality that was recently added.It would be ideal if the driver mimicked how the vault CLI's works by issuing a preflight query (see: https://github.com/hashicorp/vault/blob/master/command/kv_helpers.go#L44) to determine if a specific path is V1 or V2 and to get the mount path for the specific secret path. This would simplify the configuration of this library and allow the same paths that are provided to the vault command line tool to be used with this without the user needing to know any extra details.
Is this something that the maintainers are interested in incorporating?
My co-workers and I need the mount path support before it was added so I have a fork (https://github.com/rimitchell/vault-java-driver/tree/feature/query_vault_kv_version) containing this preflight work against the older 4.2.0 release. I am currently in the process of fixing things it against the latest release (5.1.0) (https://github.com/rimitchell/vault-java-driver/tree/feature/kvPreflight)
I've created this issue first instead of a PR as stated in the README.md because my fork changes the external contract of the library.