Forward to External Proxy not set on US region

[iaindwyer]

I'm trying to use the Proxy to External API functionality documented here but it appears that the endpoints only exist for the European region.

I tried making the call in that documentation to both mc-api.commercetools.co and mc-api.us-central1.gcp.commercetools.com and got a 404 both times. When I tried the equivalent European values I got a 401 (which would make sense, as I'm not logged into that instance).

Should I be using a different path for this region?

[tdeekens]

The feature should be available in the similar fashion on that deployment. No other path needed.

[emmenko]

Which endpoints are you talking about? The /proxy/forward-to?
Can you post here your request and how you send it?

[iaindwyer]

Yes, those are the endpoints

I'm calling to const AddProduct = () => {
fetch(https://mc-api.commercetools.co/proxy/forward-to/, {
method: 'GET',
headers: {
Accept: 'application/json',
'X-Forward-To': 'https://',
'X-Project-Key': 'ctsc'
},
credentials: "include"
}).then((response) => {alert(${response})}).catch((error) => {alert(error)})
}

I tried the same thing with mc-api.us-central1.gcp.commercetools.com and got a 404 in both cases.

If I replace them with https://mc-api.commercetools.com/proxy/forward-to/ I get a 401 instead

[emmenko]

Hmm I just tried this in the browser and it works fine

[iaindwyer]

It was another mistake in my configs; I had changed some settings to troubleshoot and hadn't switched them back. Sorry for the mistake. The JWT decoding isn't working, but I suspect that's something on my end

[tdeekens]

Hi @iaindwyer thanks for the code snippet. As a side-note: using backticks really helps readibility on things. Also the <AddProduct /> component doing a fetch inside not using an React.useEffect feels odd. That aside... I tried myself using just a CURL:

On GCP EU

curl 'https://mc-api.europe-west1.gcp.commercetools.com/proxy/forward-to' \
    -H 'x-project-key: <projectKey>' \
    -H 'x-forward-to: https://mc-api.europe-west1.gcp.commercetools.com' \
    -H 'cookie: mcAccessToken=<token>'

and I get

{ "message":"Hi, I am the API." }

On GCP US

curl 'https://mc-api.commercetools.co/proxy/forward-to' \
    -H 'x-project-key: <projectKey>' \
    -H 'x-forward-to: https://mc-api.commercetools.co' \
    -H 'cookie: mcAccessToken=<token>'

and I get

{ "message":"Hi, I am the API." }

I don't see any problem here. Plus the small CURL command really help to share and guide reproducibility on either side.

[emmenko]

The JWT decoding isn't working, but I suspect that's something on my end

@iaindwyer Let us know if we can help you with that.

PS: we're considering providing a package that includes most of the required setup for an external server to "work". See #1444
Would that be helpful in general? It can contain a middleware but also could contain a pre-configured HTTP server.

[iaindwyer]

Thanks @emmenko, I was able to get a custom lambda authorizer working with the JWT token you forward. We're using Lambdas and API Gateway for our backend implementation so in our case an HTTP server would not be helpful.

[emmenko]

I started working on a package with tools and helpers to be used by the server implementation.

See #1447

The package contains a sessionMiddleware that takes care of validating the auth request and appends a session object to the request.

I suppose you can use that in your lambda functions.

In any case, I recommend to send the following additional HTTP headers to the /proxy/forward-to endpoint:

• Accept-version: v2
• X-Project-Key

The v2 header ensures that the X-Project-Key header is present and validates that the user has access to the project, and uses the new hostnames for the issuer.
So your session middleware should use the new hostnames as the issuer.
The @commercetools-backend/express package uses the new hostnames, so we recommend to use that.

I haven't updated the docs yet, but I plan to do this by the end of this week.

Let me know if you have further questions or feature requests. Thanks