Secrets url path

[Lucretius]

This PR is to allow accessing secrets directly by visiting a URL. So, for example, if your secret is under /one/two/three/four and you go to url VAULT_URL/secrets/one/two/three then the secret four will be listed in the UI. Clicking through will now do browserHistory.push to ensure the URL is always in sync with the current secret.

[djenriquez]

Easy enough, LGTM 👍

[msessa]

What happens when a second generic backend is mounted on a path other than /secret ?

[Lucretius]

@msessa-cotd looks like I have a bit of catching up to do on the project, right now it will only handle that /secret endpoint. I'll talk with @djenriquez to figure out the details, but what will need to happen is I'll need to grab the base path and remove that instead of the hard-coded /secret. Thanks for pointing this out to me.

[msessa]

Perhaps this problem could be solved in a more generic way by having a new route which sole purpose it to view/edit objects in the vault logical filesystem using the builtin json editor.

something like:
/object?path=secret/path/name
but also for custom mounted secret backend:
/object?path=anothersecretbackend/path/name
/object?path=cubbyhole/objectname
or even configuration entries
/object?path=sys/policy/default

in fact, anything with the standard { "data" : ... } json response format.

any thought @djenriquez ?

[Lucretius]

Looks like the work got picked out of the branch it got merged to - think I may have done the work prematurely. Your solution sounds fine as well - and query string params are a bit more forgiving than dealing with paths. Not sure about opening it up beyond secrets - probably something I would ask @djenriquez about as well.

[djenriquez]

@msessa-cotd Hmm I'm understanding that you're advocating to create a new route for the express server for /object?path=... which would handle any Vault API call that responds with { "data": ...}. Is this correct?

I really think there is some benefit continuing on the path you started with the passthrough API. Normally I would agree that the above would be a good solution, but now that seems to be diverting off the route of simplifying the backend API--adding another layer of translation.

[msessa]

@djenriquez I was strictly speaking client side react. No changes in the server side nodejs code.

What I'm suggesting is basically a new react route /object that reads a path querystring from the URL bar and renders the classic vault-ui view (header, left side menu, etc) with the content panel being a full size JSON editor to read and if the token policy allows it, modify or delete any object in the vault filesystem. If policy doesn't allow a particular action on a path the UI can gracefully degrade by disabling action buttons or simply display an error message.

Basically a UI version of the standard command-line read/write/delete commands.

[djenriquez]

Ahhh, I see. So basically a generic editor providing no other Vault-UI feature but the editor itself. I can see where this can be useful.

However, this is likely out of scope for 0.2.0, let's add this as a new feature request for now.

Otherwise, I got the navigation fixed: 423ff0c

It currently however does not handle nonexistent secrets at all, so we'll need to add that.