You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
url_rewrites.path matches: version and path but not query parameters v1/fooBar
url_rewrites.match_pattern matches: listen path and version and path and query parameters myApi/v1/fooBar?baz
ignore/white_list/black_list.path matches: listen path and version and path but not query parameters myApi/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
The wildcard {id} is transformed into a wide regex ((.*)) to ensure that everything possible is captured.
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.
andyo-tyk
changed the title
extended_paths path handling is inconsistent
[TT-10626] extended_paths path handling is inconsistent
Nov 27, 2023
I can add to this. We tested with two endpoints:
/ping
/core/ping
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: