Hi Guys,

For reference, I am running this library on AWS using Elastic Beanstalk/Cloudfront/Route53. I use it to get images from HTTP image stores and and JSON data from APIs running CORS disabled webservers.

Note that I used Elastic Beanstalk over Lambda for two main reasons.

1. Technically at the time of writing, APIGateway/Lambda doesn't support image files (without base64 encoding into a JSON)
2. The high number of image requests by the application.

For lower usage applications that only need JSON or text based data, then I see no reason you couldn't deploy this using Lambda.

AWS Deployment tips w/ SSL

Some basic tips for deploying to AWS.

Elastic Beanstalk

• Create a zip file with the lib folder, server.js and package.json
• Upload and Deploy zip file to Elastic Beanstalk
• After deploy, go to Software Configuration and add an environment property for these as required:
  • CORSANYWHERE_BLACKLIST, CORSANYWHERE_WHITELIST, and/or CORSANYWHERE_RATELIMIT with your domain. E.g. www.example.com or subdomain
    E.g. For CORSANYWHERE_RATELIMIT, in order to allow any subdomain of example.com to make any number of requests and block the rest: 0 1 /(.*\.)?example\.com/
• Note the URL. E.g. myproxy.elasticbeanstalk.com

Cloudfront

• Create a new Cloudfront distribution
• Set the origin to the Elastic Beanstalk URL. E.g. myproxy.elasticbeanstalk.com
• Add a free SSL certificate using AWS certificate store.
• !! IMPORTANT !! Set the Query String Forwarding and Caching to Forward all
• Add a CNAME entry. E.g. proxy.example.com

Route53

• Add a CNAME record proxy.example.com that points to the Cloudfront URL

from cors-anywhere.

I am trying to set it up on an Ubuntu 18.04 AWS EC2 Instance with Node installed.
Running the server works, but i cannot make api calls over it. I always see an Forbidden:403 error.

Has anybody successfully set up cors-anywhere on any AWS instance or even AWS EC2?

from cors-anywhere.

I've put this on a single instance t1.micro through Elastic Beanstalk and setup Cloudfront in front of it (without a custom cname), but I'm getting an error:

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Kinda new to all of this. Can anyone suggest what I'm missing (@hutch120)? I have a tool on HTTPS making a request to the cors anywhere server behind Cloudfront on HTTPS. Ultimately going to an HTTPS endpoint. I'm assuming I setup something wrong on Cloudfront.

from cors-anywhere.

Hi @DevanB

I like to think of these CORS issues in terms of the servers involved and the path the requests take.

Consider your client and three servers:
CLI) Your client (E.g. Chrome Browser)
CF) Cloudfront (CF)
CA) ELB running cors-anywhere
DS) Some end data server that has CORS disabled.

The "preflight request" is the OPTIONS request from your client asking a server if it is ok to send the actual request.

In normal operation the OPTIONS ("preflight request") path is:
CLI -> CF (passthough) -> CA (respond OK) -> CF (OK) -> CLI (OK)

And the GET/POST/ETC path is:
CLI (URL) -> CF (URL) -> CA (URL add CORS headers) -> DS (GET DATA) -> CA (response data) -> CF (response) -> CLI (Parse Response)

The question is, which part is rejecting your OPTIONS request?

You need to check configuration.

CLI) Did you add the Access-Control-Allow-Origin header at the client?

CF) Did you allow CF to pass though OPTIONS? Is it enabled at all? Check the logs of CA, is it passing the query to the cors-anywhere server?

CA) Did cors-anywhere get a request? Check the logs. Consider adding a debug statement (See line 277 /lib/cors-anywhere.js)

DS) Is the URL correct? Does it work querying directly? (Not part of a cross origin request)

Good luck!

from cors-anywhere.

@hutch120

I commend you for this kind of response. Detailed, thorough, helpful! Let me spit-ball here:

This issue arose after I put CF in place and used HTTPS. Prior to that, in certain uses, I had no issues. So I'll try take this a layer at a time (and possibly ask questions as I progress):

CLI - I never had a "Access-Control-Allow-Origin" header in my header at the client. As I understand it, this is not something I add to my request, but rather to my response. This is what the OPTIONS call is "pre-flight checking", I think.

CF - I have checked and configured CF to use HTTPS only, and allow GET, HEAD, and OPTIONS methods. In addition, I have "Forward all, cache based on all" set for query string forwarding and caching. I am also using a Whitelist to cache selected request headers. In that whitelist I am have Origin whitelisted. I suppose I could add Access-Control-Allow-Origin, however, I still understand it to not be a request header, but rather a response header.

After checking my console again, I see I'm receiving a 504 via the OPTIONS call. And the error message points to that too by telling me that my response to preflight request doesn't pass access control. I know a 504 is a timeout error code. And looking at the log, the nginx logs have no entries with a timestamp remotely similar to the time I'm expecting. So perhaps, I have configured CF incorrectly. I have manually told it the origin domain name is the HTTP url to my beanstalk instance. Wondering if that is the issue.

Update - Odd, yeah, I can't even go to my CF url in a browser and see the CORS Anywhere information page. It seems I might have to change some settings in my EC2 instance load balancer to accept HTTPS connections. And that requires a certificate, which I can provision through ACM.

Update 2 - Gave up on it all. Moved to Heroku. That is, luckily, working much more. Only problem now is figuring out why Chrome in production isn't sending the Origin header.

from cors-anywhere.

@DevanB Tks.

CLI - Yes, sry, the Access-Control-Allow-Origin is returned by the server to the client to indicate the client is allowed to send the request.

CF - I've got two items in the whitelist... origin and referer. Note the referer is an old style of origin that I only use because I have a 3rd party JS library that still uses it.

Hmmm, not sure what else maybe check the attached screenshot of my configuration.

from cors-anywhere.

I am also interested in any experiences with running cors-anywhere on an AWS instance. I can run it ok but I am not able to access the proxy. I have opened the port the server is running but still I can't access from my local machine. Is any other configuration required? Any help will be greatly appreciated. I have searched many pages and can't find anything specific. TIA

from cors-anywhere.

I have spent today getting cors-anywhere working on an EC2 instance, using Cloudfront for https, and Route53 for a friendly name. See ndg63276/smartathome#2 for my notes. The key seemed to be getting my head around which bits were using http and which were using https, and then making sure those ports were correct, ie

• Run cors-anywhere on port 80
• open port 80 on the EC2
• tell cloudfront to use HTTP on port 80 to talk to the origin
• tell cloudfront to use HTTPS only for Viewer Protocol

Then set the cloudfront caching behaviour as mentioned in this thread (enabling OPTIONS, add "origin" to cache whitelist, Query String Forwarding and Caching set to "Forward All, Cache Based on All").

Hope that helps somebody.

from cors-anywhere.

I also tried to get it running on lambda. No success. Using AWS Apprunner was very easy.

from cors-anywhere.

I've extended this to work with aws_lambda and published it as a terraform module: lambda-cors-anywhere. It basically fetches this public repo & adds the lambda wrapper and deploys a lambda function to work with your customized allow origins.

See particularly this as the aws_lambda wrapper:
https://github.com/n-ae/terraform-aws-lambda-cors-anywhere/blob/main/aws_lambda_wrapper/index.js

from cors-anywhere.