fix TypeCommaIntSlice panic caused by json.Number input

[ccapurso]

Vault will panic when it attempts to parse fields with a schema of TypeCommaIntSlice if the provided value is an integer specifically if provided within the JSON body of an HTTP request. This is similar to a recent fix that was implemented for TypeCommaStringSlice which was fixed in #14522. The issue resides in mapstructure.StringToSliceHookFunc.

The fix provided in this pull request is to check if the raw input is of type json.Number and then calling String().

Fixes #15057

[swayne275]

what happens if it is comma separated ints e.g. 1,2?

[ccapurso]

what happens if it is comma separated ints e.g. 1,2?

@swayne275, that's a great question. Providing 1,2 as an integer would not be valid JSON and I imagine that the JSON deserialization would fail. TypeCommaIntSlice does support a comma-delimited string of integers (e.g. "1, 2") and would result in output []int{1, 2}. We cover this in a test case:
https://github.com/hashicorp/vault/blob/f5327afa4342c239178aa93d550e02120e1b5ea6/sdk/framework/field_data_test.go#L525-L535

If providing 1,2 via an HTTP request is parsed successfully resulting in a json.Number, (json.Number("1, 2") is actually valid), the String() call would then provide the same result as providing it as the string "1, 2".

[swayne275]

@ccapurso why do we use TypeCommaIntSlice in the first place then?

[ccapurso]

@swayne275, it allows users to provide []int in a flexible way. Inputs on the CLI are all strings. So providing a flag like -foo=1,2,3 from the CLI or the JSON {"foo": [1,2,3]} or {"foo": "1,2,3"} will all result in []int{1, 2, 3} on the backend.