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

nil pointer panic validating simple enum schema against invalid value #16

Closed
mcottrell1 opened this issue Aug 2, 2023 · 5 comments
Closed

Comments

@mcottrell1
Copy link

I am trying to use the schema_validation module to validate against a schema containing a single string enum property. Validation succeeds when one of the enum values is provided, but instead of giving an error when validation fails there's a nil pointer panic.

Here's a full example:

package main

import (
	"fmt"

	"github.com/pb33f/libopenapi"
	validator "github.com/pb33f/libopenapi-validator"
	"github.com/pb33f/libopenapi-validator/schema_validation"
)

const yamlSchema = `
openapi: 3.1.0
info:
  version: v1
  title: test API
  description: test api
servers:
  - url: https://localhost/api/v1
    description: test api
components:
  schemas:
    Logging:
      properties:
        logLevel:
          type: string
          enum: [critical, error, info, debug]
`

func main() {
	doc, err := libopenapi.NewDocument([]byte(yamlSchema))
	if err != nil {
		panic(err)
	}

	docValidator, errs := validator.NewValidator(doc)
	if len(errs) > 0 {
		panic(errs)
	}
	valid, docErrors := docValidator.ValidateDocument()
	if !valid {
		fmt.Printf("document validation failed: %v\n", docErrors)
	}

	model, errs := doc.BuildV3Model()
	if len(errs) > 0 {
		panic(errs)
	}
	fmt.Println(model.Model.Components.Schemas)
	schemaProxy := model.Model.Components.Schemas["Logging"]
	schema := schemaProxy.Schema()
	low := schema.GoLow()
	fmt.Println(low.Type.KeyNode)

	validator := schema_validation.NewSchemaValidator()
	obj := map[string]interface{}{"logLevel": "invalid"}
	valid, errors := validator.ValidateSchemaObject(schema, obj)
	if !valid {
		fmt.Printf("schema validation failed: %v\n", errors)
	}
}

and the output:

map[Logging:0xc00011a300]
<nil>
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x88 pc=0x7802a4]

goroutine 1 [running]:
github.com/pb33f/libopenapi-validator/schema_validation.validateSchema(0xc0000b9b80, {0x0, 0x0, 0x0}, {0x7c9600, 0xc0003410e0}, 0xc0000ce000?)
	<path>/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.13/schema_validation/validate_schema.go:170 +0x524
github.com/pb33f/libopenapi-validator/schema_validation.(*schemaValidator).ValidateSchemaObject(0x7c9600?, 0xc0003410e0?, {0x7c9600?, 0xc0003410e0?})
	<path>/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.13/schema_validation/validate_schema.go:59 +0x36
main.main()
	<path>/main.go:56 +0x276
exit status 2

It appears that schema.GoLow().Type.KeyNode is nil and the code trying to add the error attempts to use it without a nil check. Is it expected that KeyNode should ever be nil?

@daveshanley
Copy link
Member

This looks like a bug, but I can't be sure - I need to run this in my test-rig to see what the problem is. Thanks for finding this!

@daveshanley
Copy link
Member

daveshanley commented Aug 7, 2023

OK, so after looking at this, the issue lies with the assumption I made that all schemas put into the validator, will contain a type property, which is always required. Your test obj := map[string]interface{}{"logLevel": "invalid"} causes a panic, because it does not contain a type.

So the solution here is to not assume that the schema is even a schema. Because the Type property on the low-level object is always going to be nil unless that is set on the object passed in.

@daveshanley
Copy link
Member

I will create a fix and publish a new version shortly.

daveshanley added a commit that referenced this issue Aug 7, 2023
As reported in #16, types may not always exist (so the schema is completely invalid anyway). However, it’s important to make sure that we check for the type, before using it.

Signed-off-by: Dave Shanley <dave@quobix.com>
daveshanley added a commit that referenced this issue Aug 7, 2023
As reported in #16, types may not always exist (so the schema is completely invalid anyway). However, it’s important to make sure that we check for the type, before using it.

Signed-off-by: Dave Shanley <dave@quobix.com>
@daveshanley
Copy link
Member

fixed in v0.0.14

@mcottrell1
Copy link
Author

thanks for the fix and explanation, Dave. I now see that adding type: object under Logging: in the schema avoids the panic (as does your fix, of course).

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

No branches or pull requests

2 participants