-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[TT-10626] extended_paths path handling is inconsistent #5601
Comments
Hi @jakub-bochenski, Thanks for flagging this - it looks like we've got a real muddle of inconsistency there. It will be difficult to align everything without making breaking changes, but this is now on my radar. We should definitely be able to improve things in our Tyk OAS functionality, though the Tyk Classic will be tricky or impossible to resolve. In terms of the documentation, I've raised a ticket internally to improve this so that - even if the behaviour is inconsistent between different fields - we make it as clear as possible what rules are applied where. Thanks again for your support - I'll leave this open until we've managed to improve the docs. |
I can add to this. We tested with two endpoints: We put in the white_list /ping, and it is allowed, but core/ping also now is allowed. I would think this needs to be strict or clearly documented. I put /ping in the white list, and its the only endpoint in the white list, then suddenly allowing /core/ping makes no sense. I get the fact that $ at the end will stop /ping/core - but what about at the beginning of the url? |
Branch/Environment/Version
Describe the bug
For different elements in the extended_paths structure the path handling is inconsistent.
Furthermore the details are not documented (based on https://tyk.io/docs/transform-traffic/url-rewriting/ and https://tyk.io/docs/getting-started/key-concepts/versioning/)
url_rewrites.path
matches: version and path but not query parametersv1/fooBar
url_rewrites.match_pattern
matches: listen path and version and path and query parametersmyApi/v1/fooBar?baz
ignore/white_list/black_list.path
matches: listen path and version and path but not query parametersmyApi/v1/fooBar
So you have all the possible different combinations to increase confusion.
I think including version in the path is counter-productive and only produces bloat. Extended paths are configured under a particular version so there is no need to include it in the matching logic.
The same goes for listen path.
Also the documentation states
Whereas in fact I've found out that it's replaced with
[^/]*
-- see https://github.com/TykTechnologies/tyk/blob/master/gateway/api_definition.go#L721The text was updated successfully, but these errors were encountered: