Hi, I'm using vault client in a setup where my code fills up secrets in the vault which resides behind reverse proxy (YARP). In this setup I observed unexpected behavior when writing secrets under paths containing / . i.e. my/custom/path. In this scenario the secrets get incorrectly written into my%2fcustom%2fpath which I don't think is even a valid path (at least vault ui gets confused when you click on such item).
I did some investigation on my end and I was able to get into the root cause of it, which is a coefficient of two things:
Vault C# Client encodes secret paths in the POST request URL (it's done here: https://github.com/hashicorp/vault-client-dotnet/blob/main/src/Vault/Client/ApiClient.cs#L372). This produces requests like this: /v1/2c78501d-73c5-4844-908e-408d3a6440c6/data/my%2fcustom%2fpath which does not seem to be an issue on its own because vault seems to handle requests like this correctly.
YARP proxy has a known issue and does not properly recognize %2f and because of this it gets double encoded while rewriting request to the host (it's reported here: https://github.com/microsoft/reverse-proxy/issues/1419)
I'm aware it's not particularly issue with the vault client itself, but this might have some significant impact on the client library users since you don't always know what proxies exist in between the client and the vault server.
This leads me to the questions:
Is this encoding on the client side required? I did some tests and it seems the vault handles not-encoded paths as well as encoded. i.e. both of these requests to vault work just fine:
Do you think it would be worth to have it configurable for the client library user (whether encoding is enabled or not)?
What would be your recommendation to get it working in my case? (just for the record, changing reverse proxy is not an option)
I developed a workaround of supplying custom HttpClientHandler into the VaultConfiguration which decodes the path in the URL before sending request, but I'm not sure how safe it is. Could you give me some advice on this as well?
Hi, I'm using vault client in a setup where my code fills up secrets in the vault which resides behind reverse proxy (YARP). In this setup I observed unexpected behavior when writing secrets under paths containing
/. i.e.my/custom/path. In this scenario the secrets get incorrectly written intomy%2fcustom%2fpathwhich I don't think is even a valid path (at least vault ui gets confused when you click on such item).I did some investigation on my end and I was able to get into the root cause of it, which is a coefficient of two things:
/v1/2c78501d-73c5-4844-908e-408d3a6440c6/data/my%2fcustom%2fpathwhich does not seem to be an issue on its own because vault seems to handle requests like this correctly.%2fand because of this it gets double encoded while rewriting request to the host (it's reported here: https://github.com/microsoft/reverse-proxy/issues/1419)I'm aware it's not particularly issue with the vault client itself, but this might have some significant impact on the client library users since you don't always know what proxies exist in between the client and the vault server.
This leads me to the questions:
I developed a workaround of supplying custom
HttpClientHandlerinto theVaultConfigurationwhich decodes the path in the URL before sending request, but I'm not sure how safe it is. Could you give me some advice on this as well?Additional context
This is how it looks in the vault UI