Middleware response

[ewah]

We are trying to write some middleware to essentially hijack certain request (based on host/path/querystring) and forward to a different endpoint. Then rewrite the response based on a set of regular expressions to the user.

We have it able to match on path and querystring. It seems that Host is not exposed in the Request object. (point 1)

Some of the endpoints will have a querystring that need to be preserved. As far as what we could find (and read) TykMakeRequest does not support parameters. (point 2, but I can work around that w/ TykBatchRequest TykMakeHttpRequest and URL params - #9 by barcodez)

The full (mangled) Response from the endpoint , but the middleware’s request.ReturnOverrides does not support that. It only seems to support the message as an error string inside as json and the inablity to set headers. TykJsResponse does support headers and can return a full response, but is not available in middleware. (point 3, but the one that matters the most)

We’ve had some success setting up the script as a Virtual Path. Unfortunately, we would like to reuse it across a few different APIs and we cannot get past the Host/Query String matches in that Endpoint designer.

We’re looking for some idea around this.

(Ultimately, we would love love love to see something in the Endpoint Designer
match: ^http(s?)://(.*?)/abc/(.*)\?wsdl$
set variable:

• fullstring = $0
• proto = $1
• domain = $2
• path = $3
• responseAs = http$proto://$domain/abc/$path
• endpoint = https://backend.otherdomain.com/getWsdl?$path
  urlrewrite: $endpoint
  response transform substitute:
• https://backend.otherdomain.com/getWsdl?$path to $responseAs
  )

[Martin]

@ewah

Some of the endpoints will have a querystring that need to be preserved. As far as what we could find (and read) TykMakeRequest does not support parameters. (point 2

It does, but it looks like it’s not working as it should, there is a FormData parameter that should handle URL encoding values in a GET

If you take a look at the other post regarding matching in query strings, the workaround is to use a middleware/redirect/virtual path combo.

@ewah

The full (mangled) Response from the endpoint , but the middleware’s request.ReturnOverrides does not support that. It only seems to support the message as an error string inside as json and the inablity to set headers. TykJsResponse does support headers and can return a full response, but is not available in middleware. (point 3, but the one that matters the most)

Looks like you lost a paragraph there, I assume that you mean you want the middleware - which is functionally meant to modify and transform data as it passes through the gateway - as a way to hijack and return different data to the user. This has been requested many times and is something we are looking at.

@ewah

We’ve had some success setting up the script as a Virtual Path. Unfortunately, we would like to reuse it across a few different APIs and we cannot get past the Host/Query String matches in that Endpoint designer.

We’d suggest putting this code into the tyk.js file, it gets loaded into all JSVM sandboxes, so you can access the functionality there.

@ewah

(Ultimately, we would love love love to see something in the Endpoint Designer

match: ^http(s?)://(.?)/abc/(.)?wsdl$
set variable:

• fullstring = $0
• proto = $1
• domain = $2
• path = $3
• responseAs = http$proto://$domain/abc/$path
• endpoint = https://backend.otherdomain.com/getWsdl?$path
  urlrewrite: $endpoint
  response transform substitute:
• https://backend.otherdomain.com/getWsdl?$path to $responseAs

That looks lovely - feel free to add a feature request Though we’re not going to be completely overhaul how the Endpoint designer and associated functionality works any time soon.