Hi team! I am working on setting up a wiremock proxy service that my team can use to mock responses from external apis. I am hitting an issue where a proxied response that is being forwarded to the actual service is returning a 403 error. When hitting the external api directly I can connect. Is there something specific I need to do in the proxy mapping to have the authorization headers from the original request forwarded through to the real service? Currently I just have the proxy mapping for any request that hits a specific urlPath.

403 means not authorized, so something in the proxied request is missing/modified in such a way that the target system thinks the request should not be permitted. Is there any more information about what the authorization rules are and what request data is required for them?

Hi @Tom! when making the request manually I need to include an authorization header When I set up the proxy stub I didnt specifically include that header because I thought it would include any headers included with the original request. The request data only needs an ID in the body. I also didnt include that because I thought it would just include whatever was sent to the endpoint in the proxy stub. When I trigger the flow without wiremock it works but when I reroute traffic through wiremock it throws the 403. This is how I have the proxy stub set up:

{
  "name": "proxy: POST /v1.1/baskets/create",
  "priority": 100,
  "request": {
    "method": "POST",
    "urlPath": "/v1.1/baskets/create"
  },
  "response": {
    "proxyBaseUrl": "<https://realservice.com>",
    "transformers": [
      "response-template"
    ],
    "transformerParameters": {
      "requestHeaders": [
        "*"
      ]
    },
    "headers": {
      "X-Source": "proxy"
    }
  }
}

You shouldn’t have to explicitly add any request headers, except for

Host

and

Accept-Encoding

all are passed through by default.

it does require a request signature. When I make the curl manually to the wiremock service and include those specific headers it works. I think I am just misconfiguring my stub to include those

Signatures can be a pain because WireMock’s proxying isn’t completely transparent (it reconstitutes the request as a new request with some tweaks). So if the parts of the request used to construct the signature get modified slightly the server considers it to have been tampered with. At present (unfortunately) the solution sometimes is to build an extension that replicates the signing.

looking at the request in the admin api it looks like I am not sending the original host which is necessary for the signature. I am goin to try the preserveHost method in the stub to see if that lets the signature generate successfully

That may help