PathFinder finds all patterns, who looks like my request path, and he return worst case

[mrkovalchuk]

Good day. Please start from comment in code:
dcb7161#r37991936

In my case PathFinder find three path patterns (with all him staff like a response and more...):
path_pattern (from request): api/some/reourse/{key}/this/path/
Matched patterns with important arg:

1. api/some/reourse/{key}/ mimetype: json
2. api/some/reourse/{key}/this/ mimetype: json
3. api/some/reourse/{key}/this/path/ mimetype: text/csv

Ok. Could be worse. We can see, number three - best match. But code from link say: I'll return first of them. Why? Why we use iterators everywhere, but still return one response for validation? Not the most accurate pattern. Just first. Please look like it be in 0.13.2 version. Radical changes. And I don't understand new logic =(

This behaviour produce error in schema validation process. Schema right. I checked it.

Thanks for help.

[p1c2u]

Hi @mrkovalchuk

thanks for reporting the issue. It should find exactly one path. Please check #220 .

Fix #222 is already merged to master.

[mrkovalchuk]

@p1c2u Thanks for answer!

Problem isn't solved =(

Still three patterns.

[playpauseandstop]

Hi,

I ran into similar issue, when upgrading openapi-core to 0.13.3 for my projects.

First, I attempted to change OpenAPI Schema files to put paths with variables on the top, but unfortunately it didn't help much, as openapi-core==0.13.3 still matches way too many paths and I cannot ensure that request (and response) will be validated against necessary operation.

This leads me to use custom PathFinder class and define next logic in find method,

        servers_iter: Iterator[PathTuple] = self._get_servers_iter(
            request.full_url_pattern, operations_iter_peek
        )
        for server in servers_iter:
            path = server[0]
            if request.full_url_pattern.endswith(path.name):
                return server

While base PathFinder tries to return first servers_iter match instead,

        servers_iter = self._get_servers_iter(
            request.full_url_pattern, operations_iter_peek)

        try:
            return next(servers_iter)
        except StopIteration:
            raise ServerNotFound(request.full_url_pattern)

My OpenAPI schema contains next paths,

• /repositories
• /repositories/{owner}
• /repositories/{owner}/env
• /repositories/{owner}/{name}
• /repositories/{owner}/{name}/env

And change above allows BaseValidator to pick proper OpenAPI path tuple for every request.

Hope, this is helpful

[stephenfin]

I've seen this same issue, but the above solution doesn't work when validating Django responses. I ended up monkey patching the search function in openapi_core.templating.util like so:

# ...
from openapi_core.templating import util

# HACK! Workaround for https://github.com/p1c2u/openapi-core/issues/226
def search(path_pattern, full_url_pattern):
    p = util.Parser(path_pattern)
    p._expression = p._expression + '$'
    result = p.search(full_url_pattern)
    if not result or any('/' in arg for arg in result.named.values()):
        return None

    return result


util.search = search

# ... rest of code

I suspect this could be done in a far less hacky fashion if our pattern used for lookup included the type information for any parameters, as extracted from the schema. I looked into doing this with parse.Parser but I wasn't able to do so easily. I might have more luck with re but I just haven't gotten to trying this yet.

[stojan-jovic]

I think that I have same issue like described here (with version 0.13.3), so I skipped opening new issue.

Test swagger file:

paths:
  /v1/test/{test_param}:
    get:
      tags:
        - Test
      summary: Test
      description: Test
      parameters:
        - name: test_param
          in: path
          required: true
          description: Test path parameter
          schema:
            type: string
            enum:
              - test1
              - test2
      responses:
        200:
          description: Successful
  /v1/test/{test_param}/{test_param_2}:
    get:
      tags:
        - Test
      summary: Test
      description: Test
      parameters:
        - name: test_param
          in: path
          required: true
          description: Test path parameter
          schema:
            type: string
            enum:
              - test3
              - test4
        - name: test_param_2
          in: path
          required: true
          description: Test path parameter
          schema:
            type: string
            enum:
              - test5
              - test6
      responses:
        200:
          description: Successful

By making call to the second endpoint:

$ curl http://localhost:8000/v1/test/test3/test5

Request being validated against first path (i.e. /v1/test/{test_param}):

Value test3/test5 not valid for schema of type SchemaType.STRING: (<ValidationError: \"'test3/test5' is not one of ['test1', 'test2']\">,)

Simple workaround would be to change places of conflicted paths in swagger file, but I think that that will not work always (in above simple example it works).

@p1c2u Does #222 solves this? If not, I'm willing to contribute with one PR to solve issue, but not sure are you (or anybody else) already on this?

[p1c2u]

@stojan-jovic it should be fixed by #245 . Feel free to test it.

[stojan-jovic]

@p1c2u I can confirm that fix working fine! I verified it pretty much time ago, but totally forgot to respond here.

When we can expect new release? Can I somehow help with that? This is really important fix...

[timabbott]

Yeah, I'd also love to see this in a release; one has to do weird gymnastics in the OpenAPI configuration file to work around this bug.