OpenAPI Explorer (Swagger UI) "Try it out" functionality broken for ListOperations / ones with query parameters

[maxb]

Describe the bug
In the embedded Vault API Explorer (Swagger UI), the "Try it out" functionality for making requests from the UI does not work for ListOperations. It fails because the ?list=true query parameter is not added to the request.

To Reproduce
Steps to reproduce the behavior:

1. Open API explorer (Vault UI, open console dropdown, type "api")
2. Find a list operation e.g. /identity/entity-alias/id and execute it via "Try it out"
3. See error "1 error occurred:\n\t* unsupported operation\n\n"

Environment:
Vault 1.12.2 and 1.13-dev

Additional context
Issue is not unique to the mandatory list parameter on ListOperations - the allowed_client_id query parameter is also not populated into the generated request or displayed curl command properly for the /identity/oidc/provider endpoint, for example.

[maxb]

Thanks for fixing!

[vaerh]

Hello! In Vault v1.14.0, built 2023-06-19T11:40:23Z (development mode) we again have broken functionality when trying to list output. Also for this reason, reading metadata in vault-client-go doesn't work.

[maxb]

Hello! In Vault v1.14.0, built 2023-06-19T11:40:23Z (development mode) we again have broken functionality when trying to list output.

OK! But, it's not related to this closed issue, so this isn't a good place to report that.

Actually, I've just loaded up the API Explorer in 1.14.0 and both list and read operations on metadata/{path} of a KV v2 are working fine, and what you have in your screenshot appears to be Vault behaving as expected, when there are no secrets nested under path aaa/ - so I'm not convinced you're actually seeing a bug.

Also for this reason, reading metadata in vault-client-go doesn't work.

No, that's largely unrelated. I've participated in the relevant conversation at hashicorp/vault-client-go#174 and am still intending to follow through on producing a PR, though I've queued that behind my work on hashicorp/vault-client-go#180.

[vaerh]

OK! But, it's not related to this closed issue, so this isn't a good place to report that.

Sorry about that. I first posted here, but then I realized that it was better to start a new issue. What's done is done.

I assumed it was necessary to attach a screenshot with normal key data. I can tell you that the key contains information.

[maxb]

Ah, I see the issue. Thanks for including the curl commands, they're the important bit.

The issue is simply a misunderstanding / lack of docs about how the list operation works on Vault KVs.

You have a key named aaa. You do a list on aaa. You get no results. This is actually expected. (Yes, this is weird if you're comparing to the behaviour of Linux filesystems, and ls.)

Why? Because all list operations in Vault implicitly append a trailing / whether you specify one or not. You're effectively doing a list on the prefix aaa/, and the answer to the question "Do I have any secrets starting with aaa/?" is "No."

Try creating a secret aaa/bbb in addition to aaa. Then, do list operations on /v1/secret/metadata and /v1/secret/metadata/aaa and compare the results. This should allow you observe how Vault KV works, and understand why you've seen the responses you have.

[vaerh]

Try creating a secret aaa/bbb in addition to aaa. Then, do list operations on /v1/secret/metadata and /v1/secret/metadata/aaa and compare the results. This should allow you observe how Vault KV works, and understand why you've seen the responses you have.

Thanks, that's an unexpected twist :)

Then there is a back question, do I understand correctly that you can get the metadata of a single secret only with the Read function? KvV2ReadMetadata will not work with this logic.

[maxb]

Retrieving KV v2 secret metadata is always a read operation, not a list. It always operates on only a single secret.

The generated client libraries KvV2ReadMetadata function is currently broken, pending necessary changes to Vault's OpenAPI. It will work in the future, once the bug is fixed.

[vaerh]

Thank you very much for your help!

It will work in the future, once the bug is fixed.

Well, let's wait. Will the up-to-date information on bug fixing be posted as part of vault-client-go/issues/174?

[maxb]

Yes