How to use URLRewrites with CORS?

Product
, , , ,
1

Even it it wasn’t for this bug [TT-10472] CORS.options_passthrough breaks URLRewriteMiddleware · Issue #5651 · TykTechnologies/tyk · GitHub

the way URL rewrites work currently forces you to specify every endpoint twice.
E.g. if you have this

{
  "path": "match/me",
  "method": "GET",
  "match_pattern": "(\w+)/(\w+)",
  "rewrite_to": "my/service?value1=$1&value2=$2"
}

you also have to specify the same for OPTIONS

{
  "path": "match/me",
  "method": "OPTIONS",
  "match_pattern": "(\w+)/(\w+)",
  "rewrite_to": "my/service?value1=$1&value2=$2"
}

Otherwise the preflight requests will not be rewrite and the upstream server will not know how to handle them.

Having to specify every request twice sounds to me like a recipe for a lot of errors.

This would have helped but it was rejected Method name wildcards in matchers · Issue #5146 · TykTechnologies/tyk · GitHub

Am I missing something. How is one supposed to use URLRewriting while supporting CORS in Tyk?

2

Hi @Jakub_Bochenski,

Thank you for your patience.

We’d like to start by saying this is not necessarily a bug.
Looking at the request middleware chain, the cors middleware is executed much earlier than the URL rewrite middleware. It’s the design just doing what it’s supposed to at that point - passthrough to the upstream, or handle the necessary response itself. As you’ve observed, with passthrough enabled, the request is passed on to the upstream defined in the target_url (proxy.target_url).

Taking insight from this, a way around this specific scenario would be to set the “my/service” upstream server as the target_url in the API definition, and then configure url rewrite, in such a way that it would catch everything else (everything other than match/me) and rewrite to whatever you initially had as the target_url.
But this might have its trouble if you need more than just the match/me rewrite with each rewrite going to a different upstream server.

Hope this helps.
Looking forward to your response.

3

We’d like to start by saying this is not necessarily a bug.

Bugs are defined by requirements/documentation, not by implementation!

CORS.options_passthrough: allow CORS OPTIONS preflight request to be proxied directly to upstream, without authentication and rest of checks.

This doesn’t say anything about skipping middleware.

Taking insight from this, a way around this specific scenario would be to set the “my/service” upstream server as the target_url in the API definition, and then configure url rewrite, in such a way that it would catch everything else (everything other than match/me) and rewrite to whatever you initially had as the target_url.
But this might have its trouble if you need more than just the match/me rewrite with each rewrite going to a different upstream server.

I don’t follow this at all. Note we have multiple URL rewrites