Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix TypeCommaIntSlice panic caused by json.Number input #15072

Merged
merged 2 commits into from
Apr 18, 2022

Conversation

ccapurso
Copy link
Contributor

@ccapurso ccapurso commented Apr 18, 2022

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

Copy link
Contributor

@swayne275 swayne275 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ccapurso
Copy link
Contributor Author

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
Copy link
Contributor

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

@ccapurso
Copy link
Contributor Author

@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.

@ccapurso ccapurso force-pushed the fix-TypeCommaIntSlice-json-number-panic branch from f5327af to 8edb1c2 Compare April 18, 2022 19:45
@ccapurso ccapurso merged commit 9795dce into main Apr 18, 2022
@ccapurso ccapurso deleted the fix-TypeCommaIntSlice-json-number-panic branch April 18, 2022 20:43
kitography pushed a commit that referenced this pull request Apr 24, 2022
* fix TypeCommaIntSlice panic caused by json.Number input

* add changelog entry
schultz-is pushed a commit that referenced this pull request Apr 27, 2022
* fix TypeCommaIntSlice panic caused by json.Number input

* add changelog entry
schultz-is pushed a commit that referenced this pull request May 2, 2022
* fix TypeCommaIntSlice panic caused by json.Number input

* add changelog entry
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

interface conversion: interface {} is json.Number, not string in sdk/framework/field_data.go
2 participants