https://codeclimate.com/

When I run my code I get lots of warnings like this:

/Users/jcoyne85/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/openapi_parser-0.12.0/lib/openapi_parser/concerns/findable.rb:7: warning: URI.unescape is obsolete

I believe this is new in 0.12.0 and was introduced here:
02a31f6

would there be a good / easy way to support i18n?

currently, i note that the error messages are always in English, as we have not move these messages to localization strings. I'd like to be able to return these error messages in :ja for instance, but i suppose a rework on the validation modules may be needed?

Operation lookup seems get confused when the openapi spec has the following paths definition:

• "/{parent}/resource/{name}"
• "/{parent}/resource/special"

Even if I lookup with '/a/resource/special', it will always return the operation object of "/{parent}/resource/{name}"

But it works fine without that parent path param

• "/resource/{name}"
• "/resource/special"

Example spec file to reproduce the issue (file extension has been changed to txt for as github required):
spec.txt

Hello,

I'm working on building some validation for an Open Service Broker, where the broker API schema is defined using OpenAPI v3.0.0.

It allows for JSON schema to be referenced in the broker api spec itself.

Here is an example:

"schemas": {
    "service_instance": {
    "create": {
        "parameters": {
        "$schema": "http://json-schema.org/draft-04/schema#",
        "type": "object",
        "properties": {
            "billing-account": {
            "description": "Billing account number used to charge use of shared fake server.",
            "type": "string"
            }
        }
        }
    },

When running the validation, in OpenAPIParser::SchemaValidator#validate_schema,
I see the following error:

   NoMethodError:
       undefined method `any_of' for #

Looking further, the remote reference is properly resolved and the schema draft is fetched as defined in the openapi spec, unfortunately validate_schema doesn't know how to use the schema object to validate the value, especially because the schema is JSON schema.

In validate_schema(schema, value) the passed schema parameter is of type OpenAPIParser::Schemas::OpenAPI and contains the JSON schema draft and value parameter contains the schema definition itself, e.g. schema['service_instaces']['create']['parameters']

I'm using https://github.com/interagent/committee in our specs and looking for suggestions on how to handle this case? Thanks

As I wrote in interagent/committee#261 - my path of fribble/{id}.json failed to match because the OpenAPI parser expected that path parameters be "by themselves" (e.g. fribble/{id} or fribble/{id}/details.json). The legacy API I am modeling is unfortunately not this way.

I am opening the issue again on this repository because the root fix is in the parser, not in Committee.

I've made progress on a pull request to address this issue, but unfortunately it breaks some other tests. I am still looking into this, but I wanted to create the issue here, as well as post a link to the PR, so that I could begin to receive some feedback from the maintainers.

My first attempt:
https://github.com/makdad/openapi_parser/pull/1/files

Plan

OpenAPI 3.0.3 support fomat: binary so we should support it.
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#data-types

Rack set file as Rack::Multipart::UploadedFile so we should check it in string validator.
https://github.com/ota42y/openapi_parser/blob/master/lib/openapi_parser/schema_validators/string_validator.rb#L10

Other

related interagent/committee#255 (comment)

In my case, I have a query parameter defined as

{
            "name": "asAt",
            "in": "query",
            "description": "",
            "required": true,
            "schema": {
              "type": "string"
            }
          },

Validation with validate_request_parameter is always failing

According to https://github.com/ota42y/openapi_parser/blob/master/lib/openapi_parser/parameter_validator.rb#L11-L13, looks like the key in params_key_converted is not downcased when not header. However, later it tries to access the key with params_key_converted[k.downcase], which will return nil result for parameter contain upper case.

Feel free to let me know if I misunderstand the logic, cheers

Hello! Firstly, thanks for such a useful tool! We've been using openapi_parser for a long time now via committee and it's helped us significantly 🙌

I was recently looking at our schema document and had been trying to think of solutions to improve the quality of our example values on media types and schemas. I noticed that in some (many) cases, we had forgotten to update them which means that we had been showing invalid examples in generated documentation.

It made me wonder if it would be possible to use this library to validate our example objects since we can already validate other responses. I had an idea that we could maybe introduce methods such as OpenAPIParser::Schemas:Schema#validate_example! to validate the example.

While I didn't test it, I think that it could be implemented like this:

def validate_example(options) do 
  return unless example
  OpenAPIParser::SchemaValidator.validate(example, self, options)
end

The other part to this would also be to have a way to iterate over all media types and schemas in the document, this is where I am a bit stuck.

Before I looked further into it, I wanted to get your opinion on such feature. I'm happy to attempt to implement it, but some general guidance on the approach would be much appreciated.

Thanks again!

related: interagent/committee#255 #108

We have no time for adding binary string validation, but the user get error and need patch this library.
So we fix to avoid error

When referencing a ref path that cannot be resolved the following error is thrown:

#<NoMethodError: undefined method `any_of' for #OpenAPIParser::Schemas::Reference:0x000055bceb4393f8>

This error should be translated to something that better indicates the root cause.

This is a pretty minor problem since the schema should be validated against OpenApi specs to begin with.

Sample YAML file:

openapi: 3.0.0
paths:
  /api/v1/events:
    get:
      parameters:
        - in: query
          name: start_time
          description: start time
          required: true
          schema:
            $ref: "#/components/schemas/time"

It looks to me like OpenAPIParser::PathItemFinder::PathNode#find_full_path finds incorrect parameters

Given that I have this path

request_path = "/v1/objects/druid:mk420bs7601/embargo"

Then when I extract the parameters:

@root.find_full_path(request_path.split('/'))
["/v1/objects/{object_id}/embargo", {"id"=>"druid:mk420bs7601"}]

Shouldn't the second return value have a key like object_id?

https://inch-ci.org/

In my work, I tried to refer to an item with a deep hierarchy, but failed.

For example, If reference_in_responses.yaml in this gem's spec is such:

openapi: 3.0.2
info:
  version: 1.0.0
  title: OpenAPI3 Test
paths:
  /info:
    get:
      responses:
        200:
          $ref: '#/components/responses/foo/Response'

components:
  responses:
    foo:
      Response:
        description: reference response
        content:
          application/json:
            schema:
              type: object

spec fails:

Failures:

  1) OpenAPIParser::Schemas::Responses resolve reference init is expected to eq OpenAPIParser::Schemas::Response
     Failure/Error: expect(response_object.class).to eq OpenAPIParser::Schemas::Response

       expected: OpenAPIParser::Schemas::Response
            got: OpenAPIParser::Schemas::Reference

       (compared using ==)

       Diff:
       @@ -1 +1 @@
       -OpenAPIParser::Schemas::Response
       +OpenAPIParser::Schemas::Reference

     # ./spec/openapi_parser/schemas/responses_spec.rb:111:in `block (3 levels) in <top (required)>'

(The description of response_object is also ungettable)

I don't know much about OpenAPI 3, but the specification seems not to say about hierarchy limitation.
Is this expected behaviour?

coerce option don't support in header
https://github.com/ota42y/openapi_parser/blob/master/lib/openapi_parser/schemas/header.rb#L14

But OpenAPI allow integer so we should support coerce.

OpenAPI 3.1. makes the schema fully compatible with JSON schema. The library should provide support for it.

Hi!

I'm still getting started with OpenAPI. Thanks for your work on this gem!

I'm wondering if type: integer is supported in path params. I'm trying to validate that incoming URLs match the OpenAPI spec, And I want to make sure that ids are integers. Here's an example schema:

require "openapi_parser"
require "yaml"

schema = OpenAPIParser.parse(YAML.load(<<-YAML))
openapi: 3.0.1
paths:
  /items/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
YAML

I'd like URLs like /items/1 to be accepted, while URLs like /items/abc are rejected. However, When I try validate_path_params, it doesn't seem to accept 1:

request_operation = schema.request_operation(:get, "/items/1")
request_operation.validate_path_params
# Raises: 
# 1 class is String but it's not valid integer in #/paths/~1items~1{id}/get/parameters/0/schema (OpenAPIParser::ValidateError)

Is there a better way to check parameters in URLs? Or, is validate_path_params meant to be used like this?

Thanks for your help!

When using $ref to reference to whole yaml file, NoMethodError is thrown.

RSpec example that can reproduce error: master...yckimura:ref-whole-file
Failed logs: https://github.com/yckimura/openapi_parser/runs/5725197901

openapi.yaml:

openapi: 3.0.0
info:
  version: 1.0.0
  title: OpenAPI3 Test
paths:
  /whole_local_file:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: schema-object.yaml
      responses:
        '200':
          description: correct

schema-object.yaml:

type: object
required:
  - name
properties:
  name:
    type: string
  tag:
    type: string

Stacktrace:

NoMethodError:
  undefined method `any_of' for #
# ./lib/openapi_parser/schema_validator.rb:98:in `validator'
# ./lib/openapi_parser/schema_validator.rb:74:in `validate_schema'
# ./lib/openapi_parser/schema_validator.rb:62:in `validate_data'
# ./lib/openapi_parser/schema_validator.rb:45:in `validate'
# ./lib/openapi_parser/schemas/media_type.rb:15:in `validate_parameter'
# ./lib/openapi_parser/schemas/request_body.rb:24:in `validate_request_body'
# ./lib/openapi_parser/schemas/operation.rb:25:in `validate_request_body'
# ./lib/openapi_parser/request_operation.rb:52:in `validate_request_body'
# ./spec/openapi_parser/concerns/findable_spec.rb:40:in `block (4 levels) in <top (required)>'

Now we don't support path parameter in path item object

interagent/committee#305

Failure that occurred

Validation fails when using oneOf and properties in parallel.

one_of_alongside_properties:
  additionalProperties: false
  required:
    - shared_property
  properties:
    shared_property:
      type: string
  oneOf:
    - $ref: '#/components/schemas/one_of_object1'
    - $ref: '#/components/schemas/one_of_object2'

one_of_object1:
  type: object
  required:
    - name
    - integer_1
  properties:
    name:
      type: string
    integer_1:
      type: integer
  additionalProperties: false
one_of_object2:
  type: object
  required:
    - name
    - string_1
  properties:
    name:
      type: string
    string_1:
      type: string
  additionalProperties: false

Solution.

If you change the schema to use oneOf within properties instead of using oneOf and properties in parallel, the validation will work correctly.

one_of_within_properties:
  additionalProperties: false
  required:
    - shared_property
    - sample_one_of
  properties:
    shared_property:
      type: string
    sample_one_of:
      oneOf:
        - $ref: '#/components/schemas/one_of_object1'
        - $ref: '#/components/schemas/one_of_object2'

Expected results

Using oneOf and properties in parallel does not cause any particular problem with orval type generation, for example.
Thus, ideally, the openapi-parser validation should also pass.

Hi @ota42y I have add initial support for securityScheme.

Just bearer JWT support will do. I'm trying to add it in components but it seemed that i can only add code in operations object. You can take a look at pull request #143

Could you guide me on this? Thank you!

Environment

• openapi_parser
  • version: 0.3.1
• OpenAPI Specification
  • version: 3.0.1
  • format: yaml

Situation

I'm trying to test using committee_rails, but an error occurred when the definition like below.

      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  hoge:
                    type: string
        404:
          $ref: '#/components/responses/NotFound'

and components/responses/NotFound is:

components:
  responses:
    NotFound:
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'

and assert with assert_schema_conform.

As a result, 200 OK test is passed, 404 Not Found test is failed with OpenAPIParser::NotExistContentTypeDefinition

Why is this behavior?

According to the spec, strings can have their format set to date in additon to the already-supported date-time.

When the validator sees such a string, it should coerce it into a Date.

I would send a PR if there is any interest to support this feature.

Ruby 2.3 is already EOL.
So I'm going to drop ruby 2.3 support.

I think when committee drop ruby 2.3 support or we have a very difficult problem, we will drop support.

Hi,

first of all, thanks for all your efforts on this project!

I noticed that string validation for the uuid format is a bit too lax and passes on obviously non-uuid strings:

Given the following OpenAPI file

#schema.yml
openapi: 3.0.3
paths:
  /foo:
    get:
      parameters:
        - name: id
          in: query
          schema:
            type: string
            format: uuid

I would expect the following code to fail

require 'openapi_parser'
require 'yaml'

root = OpenAPIParser.parse(YAML.load_file('schema.yml'))
request_operation = root.request_operation(:get, '/foo')

request_operation.validate_request_parameter({"id" => "204730df-d3f5-364b-9aeb-d1372aba0d35-foobar"}, {})
request_operation.validate_request_parameter({"id" => "foobar-204730df-d3f5-364b-9aeb-d1372aba0d35"}, {})

But it runs without error.
I guess your regex matches as long as it finds a valid uuid substring.

Any chance of tightening this up? Would be willing to help if you think it a good idea.

it seems we currently dont handle case for email format
https://github.com/ota42y/openapi_parser/blob/master/lib/openapi_parser/schema_validators/string_validator.rb

OpenAPI 3 support require id header but openapi_parser not support yet :(

I noticed something when using Committee::Middleware::RequestValidation. It is case-sensitive in validate_header_parameter.

Therefore validation of header which is not defined in up case is not working well.

my openapi.yaml.

openapi: "3.0.2"
info:
  title: api
  version: 1.0.0
paths:
  /:
    get:
      operationId: root
      parameters:
        - $ref: '#/components/parameters/AppVersion'
      responses:
        "200":
          description: |-
            200 response
          content:
            application/json:
              schema:
                type: object
                properties:
                  status:
                    type: string
                    example: ok
components:
  parameters:
    AppVersion:
      in: header
      name: X-App-Version
      schema:
        type: string
        example: 1.0.0
      required: true

debug code

curl -X GET "http://localhost:3000/" -H "accept: application/json" -H "X-App-Version: 1.0.0"

class OpenAPIParser::ParameterValidator
  class << self
    # @param [Hash{String => Parameter}] parameters_hash
    # @param [Hash] params
    # @param [String] object_reference
    # @param [OpenAPIParser::SchemaValidator::Options] options
    def validate_parameter(parameters_hash, params, object_reference, options)
      no_exist_required_key = []
      p parameters_hash
      p params
      parameters_hash.each do |k, v|
        if params.include?(k)
          coerced = v.validate_params(params[k], options)
          params[k] = coerced if options.coerce_value
        elsif v.required
          no_exist_required_key << k
        end
      end

      raise OpenAPIParser::NotExistRequiredKey.new(no_exist_required_key, object_reference) unless no_exist_required_key.empty?

      params
    end
  end
end
# => {"X-App-Version"=>#/components/parameters/AppVersion }
# => {"VERSION"=>"HTTP/1.1", "HOST"=>"localhost:3000", "USER-AGENT"=>"curl/7.54.0", "ACCEPT"=>"application/json", "X-APP-VERSION"=>"1.0.0"}

I have a definition with minItems specified for Array type

"TestObject": {
        "type": "object",
        "required": [
          "permissions",
          "group_uuids"
        ],   
        "properties": {
          "permissions": {
            "type": "array",
            "items": {
              "type": "string",
              "enum": ["read", "write", "order"]
            },   
            "minItems": 1,
            },   
          "group_uuids": {
            "type": "array",
            "items": {
              "type": "string",
              "minLength": 1
            },   
            "minItems": 1
          }    
        }    
      }

When I pass an empty array [] for group_uuids I am hoping that it would throw a validation error.

https://coveralls.io/

Validation fails on 204 response, which has empty string as body.

Example:

paths:
  /health_check:
    get:
      description: Health check
      responses:
        '204':
          description: OK

Code

OpenAPIParser.load 'openapi.yml'
request_operation = root.request_operation :get, '/health_check'
validatable_response_body = OpenAPIParser::RequestOperation::ValidatableResponseBody.new(204, "", {})
response_validate_options = OpenAPIParser::SchemaValidator::ResponseValidateOptions.new
request_operation.validate_response_body(validatable_response_body, response_validate_options)

Expected result is truth-y, but actual result is nil.

This is btw similar to a bug in openapi-library/OpenAPIValidators#54.

Is there an option to validate and insert defaults, like json-schema?

Related issue raised at JustinFeng/fakeit#1

Looks like purge_object_cache on recursive open api specification will cause infinite method call

Currently the openapi_parser does not support remote references (https://swagger.io/docs/specification/using-ref/). Specifying remote paths cause #29 to occur.

I am not sure the effort in adding support for this feature but might be interested in contributing if I can allocate time in my upcoming sprint. If you have any thoughts on implementation feel free to post them here.

Hi! I encountered this issue while using the Committee gem but I am experiencing it directly using openapi_parser too

I'm attempting to validate a response conforms to an openapi schema like so:

    it "conforms to response schema with 200 response code" do
      root = OpenAPIParser.parse(YAML.load_file('schemas/posts.json'))
      request_operation = root.request_operation(:get, '/posts')

      actual_response = [
        {
          idd: 1,
          title: 'Post 1'
        }
      ]

      request_operation.validate_response_body(OpenAPIParser::RequestOperation::ValidatableResponseBody.new(200, actual_response, {}), OpenAPIParser::SchemaValidator::ResponseValidateOptions.new(strict: false, validate_header: false))
    end

As you can see there is typo in the actual_response

I would expect validate_response_body to raise an exception but it simply returns nil, full schema.json is here

Am I using incorrectly or is this a bug?

Working example here here

According to rubygems, openapi_parser released v0.4.1.

Could you push a v0.4.1 tag to GitHub?
And maybe the latest version written in CHANGELOG.md L3 is 0.4.1.

interagent/committee#253

I have this in one .yml file

      requestBody:
        content:
          application/json:
            schema:
              type: object
              oneOf:
                - properties:
                    session:
                      $ref: '#/components/schemas/PasswordSessionPayload'
                    device:
                      $ref: '#/components/schemas/DevicePayload'
                  additionalProperties: false
                - properties:
                    password_session:
                      $ref: '#/components/schemas/PasswordSessionPayload'
                    device:
                      $ref: '#/components/schemas/DevicePayload'
                  additionalProperties: false
                - properties:
                    sms_session:
                      $ref: '#/components/schemas/SMSSessionPayload'
                    device:
                      $ref: '#/components/schemas/DevicePayload'
                  additionalProperties: false

in an rspec test I send this body

let(:params) do
    {
      session: {
        email: user.email,
        password: "secret",
      },
      device: {
        id: "device-id",
        metadata: { "foo" => "bar" },
        platform: ["ios", "android"].sample,
      },
    }
  end

and I get the error

isn't one of in #/paths/~1session/post/requestBody/content/application~1json/schema

This yml also does not works (I get the same error)

      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                session:
                  $ref: '#/components/schemas/PasswordSessionPayload'
                password_session:
                  $ref: '#/components/schemas/PasswordSessionPayload'
                sms_session:
                  $ref: '#/components/schemas/SMSSessionPayload'
                device:
                  $ref: '#/components/schemas/DevicePayload'
              additionalProperties: false
              oneOf:
                - required: [ session, device ]
                - required: [ password_session, device ]
                - required: [ sms_session, device ]

both are valid open api yml files

Is this case of one of not supported?

Requiring openapi_parser fails with uninitialized constant OpenAPIParser::DefinitionValidatable. This happens only on 0.2.6, 0.2.5 seems to be fine.

Gemfile

source 'https://rubygems.org'

gem 'openapi_parser', '= 0.2.6'

reproducer.rb

require 'openapi_parser'

To reproduce, do the following

$ bundle install
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Using bundler 1.16.1
Using openapi_parser 0.2.6
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

$ bundle exec ruby runme.rb
Traceback (most recent call last):
        8: from runme.rb:1:in `<main>'
        7: from runme.rb:1:in `require'
        6: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser.rb:7:in `<top (required)>'                                                                                           
        5: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser.rb:7:in `require'                                                                                                    
        4: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser/schemas.rb:4:in `<top (required)>'                                                                                   
        3: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser/schemas.rb:4:in `require_relative'                                                                                   
        2: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser/schemas/openapi.rb:6:in `<top (required)>'                                                                           
        1: from /home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser/schemas/openapi.rb:7:in `<module:Schemas>'                                                                           
/home/aruzicka/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/openapi_parser-0.2.6/lib/openapi_parser/schemas/openapi.rb:8:in `<class:OpenAPI>': uninitialized constant OpenAPIParser::DefinitionValidatable (NameError)

interagent/committee#336

When I have the following schema and parameters:

xs:
  type: array
  items:
    type: object
    properties:
      x:
        type: integer

{
  "xs": [
    {
      "y": 42
    }
  ]
}

(Note that the property of the element is y, not x.)

I was expecting to get an error when validating this parameter, but it actually passed.

If I make the parameter not an array of objects, I get an error as expected.

{
  "xs": 42
}

OpenAPIParser::ValidateError:
  #/paths/~1validate_test/post/requestBody/content/application~1json/schema/properties/xs expected array, but received Integer: 42

Is there something I am missing?