"requested endpoint is forbidden" is sometimes thrown by api depending on sequence of extending paths

Support
1

Hi all,

An exception “requested endpoint is forbidden” is sometimes thrown by an API. It depends on the sequence of the extended_paths defined in the api. I have an API with the following endpoints:

  • configuration (GET)
  • configuration (PUT)
  • configuration/search(POST)
  • configuration/{id}
  • configuration/{id}

If the sequence is defined as following, it works correctly:
{
“path”: “/configuration/search”,
“method_actions”: {
“POST”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
{
“path”: “/configuration”,
“method_actions”: {
“GET”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
},
“PUT”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
{
“path”: “/configuration/{id}”,
“method_actions”: {
“DELETE”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
},
“GET”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
But if the sequence is defined as followings is doesn’t work:
{
“path”: “/configuration”,
“method_actions”: {
“GET”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
},
“PUT”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
{
“path”: “/configuration/search”,
“method_actions”: {
“POST”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
{
“path”: “/configuration/{id}”,
“method_actions”: {
“DELETE”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
},
“GET”: {
“action”: “no_action”,
“code”: 200,
“data”: “”,
“headers”: {}
}
}
},
Can you guys give an explanation why the sequence has an impact on the authorization of an API?

Are you able to reproduce this error in your own environment?

Kind regards,

Tim

2

Hi Tim,

what’s the request you’re sending, can you share your cURL?
can you share your full API Definition ?
what’s the policy attached to the key you are using?
Can you also clarify what do you mean by “has an impact on the authorization of an API” ?

Thanks,
Kos @ Tyk Support Team

3

It’s most likely that you need to always define the paths in a longest-first, Tyk CE will not sort the listen paths for you, you need to do that yourself. When the URL matcher tries to match an inbound path, it will run through the list until it finds one, so if it finds a generic (short) match first, it will skip all others.

4

@Kos, Martin already answered my question. Thanks for your reply.

@Martin, after I have imported the JSON swagger file with an incorrect import, I simply click on update button. This actually re-orders the sequence and solves the issue. Isn’t it possible to implement this “re-ordering” functionality within the import-swagger function?

Kind regards,

Tim

5

Indeed, it should do the sort there, the import swagger feature will need updating.

6

Martin,

You probably expected this question but when can we expect this fix?

Kind regards,

Tim

7

It’s not on the roadmap at the moment, so it will most likely end up in 2.4.x, which is at least 6-8 months away.

If you raise an issue on our GH racked we’all make sure it gets into a milestone.

M.

8

@Martin,

It looks like that the sorting algorithm is based on the path length. If we change the endpoint from “/configuration/{id}” to “/configuration/{identifier}” then we can’t use the “update” button to solve this issue.

I would appreciate it if you could fix this bug with a minor release. Six to eight months is a long time to solve a bug.

Kind regards,

Tim

9

Hi Tim,

Unfortunately that isn’t currently an option, we are in a release freeze as we get the next major release out the door. Minor releases are only reserved for security and emergency patches.

However, Tyk is an open source project so you can always submit a pull request :slight_smile:

Cheers,
Martin