[bruno-costanzo]

Client#with_token copies the client with dup and sets the new token on the copy. The copy also keeps the memoized API objects (@logical, @auth, @sys, ...), and those still point at the original client. So when the original client has already used #logical, a request through the copy goes out with the original token:

client = Vault::Client.new(address: "...", token: "app-token")
client.logical.read("secret/a")                       # memoizes @logical

client.with_token("user-token") { |c| c.logical.read("secret/b") }
# => sent with X-Vault-Token: app-token

The call does not fail, so this is easy to miss, and the original token is often the more privileged one.

This adds Client#initialize_copy, which clears the memoized API objects so the copy builds its own. The connection pool stays shared, as before: the token is a per-request header.

The new spec in spec/unit/client_spec.rb fails on master (both requests carry abcd-1234) and passes with the change. bundle exec rspec spec/unit: 200 examples, 0 failures.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}