Error in pattern validation

[shefali11]

While validating swagger file which has following pattern: ^[a-zA-Z0-9]{0,4096}$ gives error

Invalid components: cannot compile pattern "^[a-zA-Z0-9]{0,4096}$": error parsing regexp: invalid repeat count: {0,4096}

Issue seems golang regexp has hardcoded 1000 max reapeat Count.

Do we have any option to disable pattern validation? or any other solution.

Thank you

[fenollp]

We don't have that yet, but I do suggest passing an option through Validate(ctx) to achieve disable validation of pattern fields (opt-in).

[shefali11]

Can you please suggest any example for implementing same?

[fenollp]

I don't have a good example sorry. I'm thinking of this kind of options idea https://pkg.go.dev/github.com/getkin/[email protected]/openapi3#SchemaValidationOption but as a struct{} field in the given ctx. Plus a private package for the integer context key. Then in

kin-openapi/openapi3/schema.go

Line 581 in dc944ad

func (value *Schema) Validate(ctx context.Context) error {

you'd read ctx maybe using a dedicated accessor function and from here decide whether to do

kin-openapi/openapi3/schema.go

Line 680 in dc944ad

if err = schema.compilePattern(); err != nil {

or not.

Note that this last part is a solution to the data race uncovered in #371

[shefali11]

Thanks for the explanation.
If i understand correctly, you are suggesting not to read pattern while loading swagger.

[fenollp]

By "loading swagger" you must mean to deserialize the openapi document? In which case no, I mean to add a flag that allows skipping the verification of correctness of the field "pattern" of all schemas in the document.
Data validation against schemas would not be affected.

[shefali11]

Yes, i meant deserializing the openapi document. Adding a flag means do you want me to make changes for this as currently in schema validation we are checking if err = schema.compilePattern(); and here we are not checking if that flag exists.

[TristanSpeakEasy]

Has there been any update on this, we are attempting to parse 3rd party openapi schemas where we can't change the contents of the file and have run into a number of issues where we fail to load the file due to it failing regex validation even though we don't use the compiled pattern ourselves, just require the raw string

[TristanSpeakEasy]

@fenollp I have created a PR for allowing pattern validation to be disabled as this is core to us supporting some 3rd party specs that we can't change the pattern in

#590