ui: some chars destroys the list view until page reload / the "View secret" prompt should not be cached

[Schluggi]

Describe the bug If you type-in "/ into the secret filter you get an error that prevent you to see any secret until you go back and reload the page.

To Reproduce

1. Go to the UI
2. Select any secret engine
3. Use the secret filter and type-in "/
4. You should see this:
5. Go back to the overview of the secret engines
6. Navigate to the same engine you select in 2.
7. The view is still the same as in 4.
8. Reload the page (for example by pressing F5) and you'll get back your list view

Expected behavior First of all i don't think the chars should have this effect at all. I would expect the "There are no secrets matching" massage to appiers. Moreover the browser should not cache this message. On point 7 I would expect to see the list view that I can see after reloading the page because the filter value is not longer path of the url.

Environment:

• Vault Server Version (retrieve with vault status): 1.9.2
• Vault CLI Version (retrieve with vault version): v1.9.2
• Server Operating System/Architecture: CentOS 7

Vault server configuration file(s): I can't paste any configuration files due to our company guidelines :/

Additional context This issue maybe relates to #13866 and first notices after upgrading from v1.6.3 to v1.9.2.

The "View secret" prompt (I shared in the image) is also cached if I try to open an engine without having the list permissions:

1. Open an engine without having the list permissions
2. The "View secret" prompt appiers
3. Go to eny other engine where you have the list permission
4. The "View secret" prompt is still there
5. Reloading the page fixes the view

Sometimes the "View secret" prompt also appiers and get cached after deleting a secret. But I was not able to reproduce this. I think there is a general problem whith the caching method of this prompt.

[heatherezell]

Hi there! We're having some trouble reproducing this internally: Can you provide more information about the policies being used here? Also, can you verify that both your server and your UI are on 1.9.2? Thanks! :)

[tizzir]

I seem to be encountering the same issue with Vault 1.9.3. If I attempt to access a secret folder that I don't have access to (no list permission,) as expected, I receive the "View secret" text box.

However, when I then navigate to a folder that I do have access to, I see the same "View secret" text box, rather than a list of secrets. Refreshing this second folder allows me to see the values again.

Worth noting, is that by inspecting the response from the second /<secretengine>/metadata/<foldername>/?list=true endpoint (the one that I have list permission on,) I can see the values that I expect to be listed:

{"request_id":"<ID>","lease_id":"","renewable":false,"lease_duration":0,"data":{"keys":[<my keys listed here>]},"wrap_info":null,"warnings":null,"auth":null}

This seems to confirm that the issue lies on the UI side. As the @Schluggi suggests, perhaps the browser thinks it should be caching the "View secret" page?

Could this be a misconfiguration issue with the reverse proxy server?

[heatherezell]

Thanks @tizzir! This helps. We'll do some more investigation and see if we can repro it with this information. :)

[heatherezell]

This is fixed in #13880 and will be in 1.10. Thanks for your patience!