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

base64 type properties fail validation for lack of example #132

Open
shoffmeister opened this issue Oct 31, 2020 · 8 comments
Open

base64 type properties fail validation for lack of example #132

shoffmeister opened this issue Oct 31, 2020 · 8 comments
Assignees
Labels

Comments

@shoffmeister
Copy link

shoffmeister commented Oct 31, 2020

Whenever an object has a property of base64 (i.e. type: string, format: byte) validation will fail the error message

*ERROR* in Model '...', property 'content', field 'example' -> This field should be present and not empty

although the field example is present. This is really tied to the property being of type base64; remove the "format: byte" and the specification document will pass validation.

To reproduce, download the attached Zip file y.zip which contains two files minimally reproducing:

  • pom.xml
  • broken-validation-base64-response.yaml

Run mvn verify

//exp: passes validation
//act: ERROR in Model

@JFCote
Copy link
Member

JFCote commented Nov 2, 2020

@shoffmeister Thanks for the bug report! I'm not sure when I'll be able to look at this, I'm very busy for the next 2 weeks but if you send me a PR, I will try to review it quickly and make sure we do a release. Otherwise, it might take a couple of weeks.

Thanks!

@JFCote JFCote added the bug label Nov 2, 2020
@JFCote JFCote self-assigned this Jan 22, 2021
@JFCote JFCote added this to the v1.6.0 milestone Jan 22, 2021
@JFCote JFCote modified the milestones: v1.6.0, v1.7.0 Mar 17, 2021
@JFCote JFCote removed this from the v1.7.0 milestone Jun 29, 2021
gervaisb added a commit to gervaisb/openapi-style-validator that referenced this issue Nov 25, 2021
@gervaisb
Copy link
Contributor

@JFCote
Copy link
Member

JFCote commented Nov 26, 2021

@gervaisb So either it's a bug with swagger-parser that we use under the hood or swagger-parser follow specification and a byte field should not have example. I can't find any specific information about the byte field examples here: https://swagger.io/docs/specification/adding-examples/

If it's a bug: We need to create a bug in their project. https://github.com/swagger-api/swagger-parser

If it's meant to be like that and follow spec, we need to create a special validation that when the field is "byte", we don't count it as an error when there are no examples.

I don't have time right now to dig deeper but if you have some time, you could go and create an issue in their project since you already have examples.

@gervaisb
Copy link
Contributor

It seems to be a bug on the parser that tries to cast the example to the wrong type: swagger-api/swagger-parser#1630 (comment)

@tymonx
Copy link

tymonx commented Dec 27, 2021

I have the same issue here. As temporary workaround I use format: base64 with additional pattern: '^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$'.

@JFCote
Copy link
Member

JFCote commented Jan 3, 2022

@gervaisb and @tymonx. As soon as swagger-parser release a new version with this fix, I will update our dependency and create a new release.

Thanks for the workaround in the meantime! :)

@acabarbaye
Copy link

same seems to be true with format: binary

@gervaisb
Copy link
Contributor

Hello there,

The parser has been patched, it will now automatically get the bytes of a string. However, there are some implications with this fix, see this comment in the issue: swagger-api/swagger-parser#1630 (comment)
We should be able to fix that issue as soon as they release that fix.

However, regarding the opinionated issues mentioned in the linked comment, should we not support the new swaggerParserBinaryAsString property too?

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

No branches or pull requests

5 participants