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

OpenAPI 3.0: no validation for request body parameters in try it out #9673

Open
glowcloud opened this issue Mar 7, 2024 · 3 comments
Open

Comments

@glowcloud
Copy link
Contributor

glowcloud commented Mar 7, 2024

Describe the bug you're encountering

Swagger UI does not show validation errors on try it out for object parameters in OpenAPI 3.0 specifications.

To reproduce...

Steps to reproduce the behavior:

  1. Go to https://petstore3.swagger.io/
  2. Navigate to /store/order POST request
  3. Click on try it out button
  4. Change id to test
  5. Click on execute button
  6. See no errors
Screenshot 2024-03-07 at 14 50 36

Expected behavior

Swagger UI should validate incorrect input and show validation errors to the user. The errors will show for 2.0 specifications and for primitive parameters in 3.0:

Screenshot 2024-03-07 at 14 48 53
@glowcloud glowcloud self-assigned this Mar 8, 2024
@glowcloud glowcloud changed the title OpenAPI 3.0: no validation for object parameters in try it out OpenAPI 3.0: no validation for request body parameters in try it out Mar 11, 2024
@glowcloud
Copy link
Contributor Author

It looks to me like we don't validate parameters at all for application/json and application/xml.

When checking for required fields, we skip the JSON validation:

// context: json => String; urlencoded, form-data => Map
if (!Map.isMap(oas3RequestBodyValue)) {
return missingRequiredKeys

If the request content type is set to application/x-www-form-urlencoded, the validation of required parameters is being done, although it looks to me like it might be missing for arrays. There's also no validation of types. In the screenshot, id is a string instead of integer and the photoUrls array is empty but there's no error. The required name is correctly shown as missing.

Screenshot 2024-03-13 at 09 08 52

Here's the result of execution with correctly added name but empty photoUrls

Screenshot 2024-03-13 at 09 30 06

It looks like the only validation for application/json and application/xml is done for the required requestBody itself:

Screenshot 2024-03-13 at 09 35 42

@glowcloud
Copy link
Contributor Author

There is also an issue with OpenAPI 2.0 - we don't validate required parameters in bodies but we do validate their types. It seems that the issue lies here:

if(schema && schema.has("required") && isFunc(requiredBySchema.isList) && requiredBySchema.isList()) {
requiredBySchema.forEach(key => {
if(objectVal[key] === undefined) {
errors.push({ propKey: key, error: "Required property not found" })
}
})
}

We should be using List.isList(requiredBySchema) in this if check.

For OpenAPI 3.0, it looks like here

const paramValues = parameterValues(state, pathMethod).toJS()

we're not getting the parameters for request body because, from looking at the OAS3 reducers, ex. here
return state.setIn(["requestData", path, method, "bodyValue"], newVal)

we're setting them in a different path that isn't being checked when we get the params.

We have a method that should be validating request body separately

handleValidateRequestBody = () => {

but it looks like we don't check the types of values there at all and, as mentioned before:

When checking for required fields, we skip the JSON validation:

// context: json => String; urlencoded, form-data => Map
if (!Map.isMap(oas3RequestBodyValue)) {
return missingRequiredKeys

@JaredAAT
Copy link

Again, I remain unconvinced that the client should be validating the input, it should be down to the server to validate what is being sent. There are good reasons why you may want to send invalid payloads from the client.

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

No branches or pull requests

2 participants