CORS headers in response

[strogonoff]

Here is an error I get when accessing the “list codes” endpoint from browser:

Access to XMLHttpRequest at 'https://zkjrxjsleh.execute-api.us-east-1.amazonaws.com/prod/interscript' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The server probably just needs to pass “Access-Control-Allow-Origin” in response. For now it’d be nice if it was a wildcard (in future it could be limited to “interscript.com”).

cURL equivalent of browser request (this works from Terminal, which does not do CORS checks):

curl 'https://zkjrxjsleh.execute-api.us-east-1.amazonaws.com/prod/interscript' \
-X 'POST' \
-H 'Accept: application/json, text/plain, */*' \
-H 'Content-Type: application/json' \
-H 'Origin: http://localhost:3000' \
-H 'Referer: http://localhost:3000/' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15' \
--data-binary '{systemCodes}'

[ronaldtse]

If it’s deployed does it go away?

[strogonoff]

I believe this will be the case even if site is deployed to a proper domain and API is deployed on a subdomain within that domain, and a header probably has to be returned anyway.

This can probably be done either on Lambda@Edge level or on Ruby level

[phuonghuynh]

No, it is not deployed to sub domain for now, I am working on it It can be done on API Gateway level @ronaldtse

[ronaldtse]

@phuonghuynh can you help deploy it to subdomain? We need this done ASAP..

[strogonoff]

Just to clarify, deployment to a subdomain will not help with the CORS error. If CORS headers are returned, though, it doesn’t matter where it is deployed. Sorry if my previous comment was vaguely phrased

[strogonoff]

The quickest fix to address it right now should be to just return Access-Control-Allow-Origin: * with all API responses

(And possibly Access-Control-Allow-Methods: POST, GET, OPTIONS)

[ronaldtse]

We still need to deploy to a subdomain because www.interscript.com points to the s3 bucket. In any case, CORS header needs to be supplied.

[strogonoff]

Sure. It doesn’t matter where it points though, from user perspective it should work

[strogonoff]

@phuonghuynh, ping—let’s return CORS headers with API response (this is an issue that prevents this API from being called from client-side browser JS)

[phuonghuynh]

@strogonoff fixed now, bellow is testing cURL cmd return 200.

API_URL="https://api.interscript.com"
curl -XPOST ${API_URL} \
  -H 'Origin: http://sample.com' \
  -H "Access-Control-Request-Method: POST" \
  --verbose \
  --data-raw '{transliterate(systemCode: "bgnpcgn-arm-Armn-Latn-1981", input: "Հայերէն")}'

[ronaldtse]

@phuonghuynh can you limit CORS to only allow www.interscript.com? Thanks.

[phuonghuynh]

@ronaldtse done, rite now, it is hard-code in lambda ruby api

curl -i -X OPTIONS https://api.interscript.com \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: Content-Type, Accept' \
  -H 'Origin: https://www.interscript.com'

[ronaldtse]

@phuonghuynh are we using API Gateway with Lambda? https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

CORS is definitely an infrastructure configuration thing, not a code thing.

We should use terraform to set the CORS headers using API Gateway: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-cors.html

[phuonghuynh]

Yes, but proxy to lambda requires lambda functions also response cors header.

[ronaldtse]

But API gateway allows setting CORS headers? https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-cors.html

[strogonoff]

Thanks, works. It restricts origin to interscript.com so I can’t test it from localhost easily (dev environment requires Host to be “localhost” so I can’t just set an entry in /etc/hosts) but that’s fine for now

[phuonghuynh]

@ronaldtse yes, our gateway implemented a mock to response to OPTIONS request (preflight) ; due to AWS document, lambda proxy is required to return CORS also

https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html

Enabling CORS support for Lambda or HTTP proxy integrations For a Lambda proxy integration or HTTP proxy integration, you can still set up the required OPTIONS response headers in API Gateway. However, your backend is responsible for returning the Access-Control-Allow-Origin and Access-Control-Allow-Headers headers, because a proxy integration doesn't return an integration response.

[phuonghuynh]

@strogonoff could we use proxy config in webpack? https://webpack.js.org/configuration/dev-server/#devserverproxy ,

I did not use it but there is a proxy feature in Angular could solve this issue, https://angular.io/guide/build#proxying-to-a-backend-server

[strogonoff]

It’d be definitely possible to work around dev server limitation, webpack or not.

(CORS could whitelist localhost as well, but not strictly necessary)

On 13 Aug 2020, at 3:50 AM, phuong notifications@github.com wrote:

 @strogonoff could we use proxy config in webpack? https://webpack.js.org/configuration/dev-server/#devserverproxy ,

I did not use it but there is a proxy feature in Angular could solve this issue, https://angular.io/guide/build#proxying-to-a-backend-server

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.