Allow formatted data when using -field and -format together.

[jefferai]

As a special case, allows "data" to be passed in to get the entire data
struct output.

[vishalnayak]

Tested this. The output looks neat! LGTM!

[vishalnayak]

@jefferai

payload.json
{
        "data": {
                "foo": "bar",
                "bar": ["foo", "bar"],
                "baz": {
                        "bar": "baz"
                }
        }
}

vault write secret/foo raw=@payload.json
vault read -format json -field raw secret/foo

Has a different output before and after the fix.

[jefferai]

I'm aware of that edge case but there's no real way to solve it. The only thing to do might be to see if the map has a data key and if so use that instead. Either way in one case or the other it won't work, it's just a matter of which will be more common. And of course in advanced usage like that people can just hit the API directly.

[jefferai]

Actually what you are seeing above is a different thing. When you use raw=@payload.json what gets sent up to Vault is the string output of the file, json-encoded. So when you use -format=json -field=raw, now, it correctly fetches that one field, which is a string, and outputs it in a JSON-compatible way, which is its existing form. So this is actually correct behavior now.

What you can/should do there is simply not specify format=json so that the raw output is used for the field. This causes the shell to interpret the newlines, which produces the output you want. Since -format wasn't actually used with -field in prior version, simply not specifying format=json just falls back to previous behavior.

[jefferai]

Also note that if you send @payload.json directly as the value in the CLI, since you're not assigning it as a value for the key raw (which is always string=string in the CLI), then it goes up as a struct, not a string, and -format=json with -field do the right thing. So basically this is just allowing less garbage :-)

[vishalnayak]

@jefferai Yep. Had tested the sending of @payload.json directly and had verified that the behavior was proper. I also had tested the behavior which the reporting user was using as a workaround. I agree that the behavior we notice is right (since we are encoding the value as a string). So, all good.