[BUG] OpenAPI Spec Failing to Parse about openapi-parser HOT 7 CLOSED

Hello, did you find any solution for the problem? I am facing the same problem and i still could not find a work around.

from openapi-parser.

I have the same problem.

from openapi-parser.

Same problem, any solutions?

from openapi-parser.

@theemanofsteele it works fine for me, see below.

Try to compile and run the project on this repo and reopen the ticket if your error persists.

from openapi-parser.

@theemanofsteele it works fine for me, see below.

I'd like to add that this issue is not fixed yet, I have the same problem. What @theemanofsteele said is that the provided spec (the one you tested) indeed works, but his custom spec doesn't.

I tried with my custom spec using a freshly compiled version from this repoand got the exact same error message. My spec is valid in swagger-ui, and the error messages do not add any information on where the spec supposedly is wrong.

from openapi-parser.

Sorry for the delayed response. I should have been updating sooner.

So we are still seeing this issue. However. I don't know that I feel justified to reopen it. I'll explain.

What we have discovered is that our API Spec files are almost correct. We've been using Swagger Editor and other linters to "validate" the API spec. On the surface, it seems that everything is OK. It would seem a lot of tools are fairly "forgiving" when it comes to processing/parsing a OAS file. This particular Burp extension however, is not so forgiving. For example, we had a section in one of our specs that looked similar to this (paraphrased)...

paths:
  /foo/bar/v1/data:
    get:
      summary: Get data
      tags:
        - data
      security:
        - bearer: []
      parameters:
        - name: data
          in: query
          required: false
          schema:
            $ref: "#/components/schemas/data"
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/dataResponse"

If you were to check this against the Swagger Editor, it would give it a "pass". But the Burp extension didn't like that. This is where we'd see the parameter4 null error. So after some trouble shooting we discovered what it was complaining about. The OAS documentation has an example on a typical paths object: https://swagger.io/specification/v3/#paths-object. Specifically, we needed to our parameter to look like this:

schema:
  type: array
  items:
    $ref: "#/components/schemas/data"

Once we changed our specs to follow that pattern, we'd get past that error. There have been some other smaller similar issues but once we discovered this, we've been able to troubleshoot our own specs and have been able to get the Burp extension to accept our OAS files.

It's not ideal but I don't necessarily hold @aress31 at fault here. The extension parses successfully once we have the spec formatted right. It's just tough to know exactly what it wants. The error messages are no where near helpful. And at the same time, Swagger Editor and other linters are telling us our OAS files are good when in reality, they do have faults that should be caught.

Hopefully that is helpful for those following along.
RE: @JasperSurmont

from openapi-parser.