[BUG]: Hashicorp Vault secret mount name can't contain '/'

[yafanasiev]

OS: macOS 14.4.1 (23E224) (Intel)
Teller version: 2.0.5

Description:
Given the following sample configuration

providers:
  hashicorp_vault:
    kind: hashicorp
    maps:
      - id: test
        path: 'foo/bar/test'

where foo/bar is a secret mount name (including forward slash), and test is a secret path, Teller fails with the following error:

APIError { code: 404, errors: ["no handler for route \"foo/data/bar/test\". route entry not found."] }
Error: NOT FOUND foo/bar/test: not found

Location:
   /private/tmp/teller-20240515-8094-43x90q/teller-2.0.5/teller-cli/src/cli.rs:266:23

Judging from request, Teller treats part of the path up to the first slash as a secret mount name and builds the Vault request accordingly, which is incorrect in our case.

I already tried URLencoding the slash character, escaping, double escaping etc.

With Teller v1, the following configuration was working for us:

path: foo/bar/data/test

[jondot]

Thanks for this report!
This is interesting, we currently solve the mount inference in a new way - the first segment up until the first / is the mount. What you present is a mount that includes a / as part of the name of the mount.

I'd be happy to get an idea for how to change the mount inference logic that can accommodate for that but also be easy and transparent to users, that you think might work

[jondot]

Meanwhile I can also suggest a format like:

• foo/bar://data/test
• foo/bar:data/test
• foo/bar//data/test

of course, first attempt would be at one agreed structured format, and if not found, fallback to taking the first segment like today.

any feedback / ideas?

[yafanasiev]

Would you be open to roll back to old behaviour where we had to specify the full KV2 path to secret (including data in path)?

[jondot]

Im open to ideas
Could you give a few examples?
Specifically I’m worried about how the mount will be specified

[yafanasiev]

Hey @jondot! Sorry for the delay. How about your suggestion with foo/bar://data/test? Seems nice to me

[romans-ovo]

I have provided an implementation for foo/bar//data/test as i think it's a simpler format, but if you prefer foo/bar://data/test then it just needs .split_once("://"); in my PR.