CORS Proxy

This is a simple CORS proxy that was originally developed for anychan web application.

Based on cors-anywhere with some changes.

Use

Create a new folder. Go into it. Initialize a new Node.js project in it:

``



npm init





Call your project any name. Answer the questions it asks.



After it finishes setting up the project, install

cors-proxy-node

 dependency:



npm install cors-proxy-node --save





Create a new file

index.js

js

import corsProxy from 'cors-proxy-node'



corsProxy({

  host: '0.0.0.0',

  port: 8080

})

In

package.json, add a new script called start

js

"scripts": {

  "start": "node index.js"

}





Start the proxy using the command:



npm start





To proxy a URL through the CORS proxy, one could send an HTTP request to:



*

/?url=





For example, if

host is set to "0.0.0.0" and port is set to 8080, then to proxy https://google.com

 URL through the CORS proxy, one could send an HTTP request to:



*

http://my-cors-proxy.com:8080/https://google.com

http://my-cors-proxy.com:8080/?url=https%3A%2F%2Fgoogle.com





Configuration



Configuration is very simple and should be specified in

config.json

 file.



*

host: string — The hostname to listen on. The simplest value that always works is "0.0.0.0" which means "listen on all possible host names for this host". This parameter is ignored when HOST

 environment variable is set.



*

port: number — The port to listen on. Example: 8080. This parameter is ignored when PORT

 environment variable is set.



*

fromOriginWhitelist?: string[]

 — An explicit "whitelist" of allowed HTTP origins to accept proxy requests from. If this configuration parameter is specified then only those HTTP origins will be allowed to send HTTP requests to this proxy server. Otherwise, all incoming HTTP requests are allowed, regardless of the HTTP origin they came from.



*

toOriginWhitelist?: string[]

 — An explicit "whitelist" of allowed HTTP origins to accept proxy requests towards. If this configuration parameter is specified then any incoming HTTP requests towards those destination origins are allowed, regardless of the

fromOriginWhitelist

 setting.



*

cookies?: boolean — Set to true to enable cookies. Cookies are disabled by default. Enabling cookies requires setting both fromOriginWhitelist and shareCookiesBetweenOriginsInFromOriginWhitelist parameters. Enabling cookies is required when calling fetch() with credentials: "include"

 parameter.



*

shareCookiesBetweenOriginsInFromOriginWhitelist?: boolean — An explicit "opt-in" flag that is required to be set to true

 when enabling cookies. The only purpose of this flag is to make it explicit that, when enabled, cookies are shared between all originas in

fromOriginWhitelist

 because not everyone realizes that. I myself didn't realize it.







$3



####

x-cookie





Web browsers don't allow client-side javascript code to set the value of the

cookie header of an HTTP request. To work around that, there's an x-cookie header: if specified, the contents of x-cookie request header will be appended to the cookie request header using "; "

 as a separator. This is a way to add any additional cookies to a proxied HTTP request.



####

x-set-cookies





Web browsers don't expose

set-cookie

 headers of an HTTP response to client-side javascript code. To work around that limitation and see what cookies exactly have been set by the server, one could pass an HTTP request header called

x-set-cookies with value true. In that case, the HTTP response is gonna contain a header called x-set-cookies whose value is gonna be a stringified JSON array of all set-cookies

 headers' values, if there were any in the server's response.



Trivia: There can be several

set-cookie

 headers in a given HTTP response: one for each cookie. That's how it's defined in the HTTP specification.



####

x-redirect-status





When specified, replaces status

30x in HTTP response with the value of this header. This allows to bypass the weird behavior of the fetch() function: otherwise, when it receives HTTP response status 302 in CORS mode, it doesn't allow the application to look into the response details and instead sets response.status to 0 and response.headers to empty headers. Issue. Replacing response status 302 with something else like 200

 allows a developer to bypass that weird behavior and examine the status and headers of the response.



####

x-follow-redirect





Redirects are automatically followed unless the request header

x-follow-redirect is explicitly set to false

.



When automatically "following" a chain of redirects, it must concatenate all

set-cookie response headers in the chain and output the result in set-cookie

 header of the final response.



$3















####

x-set-cookies





See the description of the

x-set-cookies

 request header.



####

x-redirect-status





When passing

x-redirect-status header in request to override a redirect status, in case of a redirect, it will add an x-redirect-status

 header in response with the value of the original response status (before the override).



####

x-redirect-n





For debugging purposes, each followed redirect results in the addition of an

x-redirect-n response header, where n starts at 1

. The value of each such header is comprised of the redirect status code and the redirect URL separated by a whitespace.



After 5 redirects, redirects are not followed any more. The redirect response is sent back to the browser, which can choose to follow the redirect (handled automatically by the browser).



####

x-request-url





The requested URL.



####

x-final-url





The final URL, after following all redirects.



Hosting



$3



Original article



* Create a repo on GitLab or GitHub with the contents of the proxy folder.

* Create

vercel.json

 file in the repo. It sets up Vercel hosting for the repo:

js

{

  "version": 2,

  "name": "nodejs-mysql",

  "builds": [

    { "src": "index.js", "use": "@vercel/node" }

  ],

  "routes": [

    { "src": "/(.*)", "dest": "/index.js" }

  ]

}





* Push the changes to the repo.

* Login to Vercel using your GitLab or GitHub account.

* Click "Add New" → "Project".

* Choose "GitLab" or "GitHub".

* Find the repo in the list and click the "Import" button next it.

* After the project has been deployed, it will show the website URL for it. Use it as a proxy server URL. Example:

https://my-cors-proxy.vercel.app?url={urlEncoded}

.







Restrictions



To prevent the use of the proxy for casual browsing, the proxy requires one of the following request headers to be present:

*

origin

x-requested-with





Stats



There's a basic "stats" page available at

/stats

 URL. It displays a list of the most recent requests to the proxy: date, time, user subnet's IP address hash (in a form of a single unicode character) and the proxied URL.



When running in a containerized environment like Vercel, the proxy instance might be stopped when it doesn't receive incoming HTTP requests and then started again when an incoming HTTP request arrives. Any stats will be naturally cleared during such restart.

`CORS Proxy`





This is a simple CORS proxy that was originally developed for anychan web application.



Based on cors-anywhere with some changes.



Use



Create a new folder. Go into it. Initialize a new Node.js project in it:



``

npm init

`



Call your project any name. Answer the questions it asks.



After it finishes setting up the project, install cors-proxy-node dependency:



`

npm install cors-proxy-node --save

`



Create a new file index.js:



`js

import corsProxy from 'cors-proxy-node'



corsProxy({

  host: '0.0.0.0',

  port: 8080

})

`



In package.json, add a new script called start:



`js

"scripts": {

  "start": "node index.js"

}

`



Start the proxy using the command:



`

npm start

`



To proxy a URL through the CORS proxy, one could send an HTTP request to:



* /

* /?url=



For example, if host is set to "0.0.0.0" and port is set to 8080, then to proxy https://google.com URL through the CORS proxy, one could send an HTTP request to:



* http://my-cors-proxy.com:8080/https://google.com

* http://my-cors-proxy.com:8080/?url=https%3A%2F%2Fgoogle.com



Configuration



Configuration is very simple and should be specified in config.json file.



* host: string — The hostname to listen on. The simplest value that always works is "0.0.0.0" which means "listen on all possible host names for this host". This parameter is ignored when HOST environment variable is set.



* port: number — The port to listen on. Example: 8080. This parameter is ignored when PORT environment variable is set.



* fromOriginWhitelist?: string[] — An explicit "whitelist" of allowed HTTP origins to accept proxy requests from. If this configuration parameter is specified then only those HTTP origins will be allowed to send HTTP requests to this proxy server. Otherwise, all incoming HTTP requests are allowed, regardless of the HTTP origin they came from.



* toOriginWhitelist?: string[] — An explicit "whitelist" of allowed HTTP origins to accept proxy requests towards. If this configuration parameter is specified then any incoming HTTP requests towards those destination origins are allowed, regardless of the fromOriginWhitelist setting.



* cookies?: boolean — Set to true to enable cookies. Cookies are disabled by default. Enabling cookies requires setting both fromOriginWhitelist and shareCookiesBetweenOriginsInFromOriginWhitelist parameters. Enabling cookies is required when calling fetch() with credentials: "include" parameter.



* shareCookiesBetweenOriginsInFromOriginWhitelist?: boolean — An explicit "opt-in" flag that is required to be set to true when enabling cookies. The only purpose of this flag is to make it explicit that, when enabled, cookies are shared between all originas in fromOriginWhitelist because not everyone realizes that. I myself didn't realize it.







$3



#### x-cookie



Web browsers don't allow client-side javascript code to set the value of the cookie header of an HTTP request. To work around that, there's an x-cookie header: if specified, the contents of x-cookie request header will be appended to the cookie request header using "; " as a separator. This is a way to add any additional cookies to a proxied HTTP request.



#### x-set-cookies



Web browsers don't expose set-cookie headers of an HTTP response to client-side javascript code. To work around that limitation and see what cookies exactly have been set by the server, one could pass an HTTP request header called x-set-cookies with value true. In that case, the HTTP response is gonna contain a header called x-set-cookies whose value is gonna be a stringified JSON array of all set-cookies headers' values, if there were any in the server's response.



Trivia: There can be several set-cookie headers in a given HTTP response: one for each cookie. That's how it's defined in the HTTP specification.



#### x-redirect-status



When specified, replaces status 30x in HTTP response with the value of this header. This allows to bypass the weird behavior of the fetch() function: otherwise, when it receives HTTP response status 302 in CORS mode, it doesn't allow the application to look into the response details and instead sets response.status to 0 and response.headers to empty headers. Issue. Replacing response status 302 with something else like 200 allows a developer to bypass that weird behavior and examine the status and headers of the response.



#### x-follow-redirect



Redirects are automatically followed unless the request header x-follow-redirect is explicitly set to false.



When automatically "following" a chain of redirects, it must concatenate all set-cookie response headers in the chain and output the result in set-cookie header of the final response.



$3















#### x-set-cookies



See the description of the x-set-cookies request header.



#### x-redirect-status



When passing x-redirect-status header in request to override a redirect status, in case of a redirect, it will add an x-redirect-status header in response with the value of the original response status (before the override).



#### x-redirect-n



For debugging purposes, each followed redirect results in the addition of an x-redirect-n response header, where n starts at 1. The value of each such header is comprised of the redirect status code and the redirect URL separated by a whitespace.



After 5 redirects, redirects are not followed any more. The redirect response is sent back to the browser, which can choose to follow the redirect (handled automatically by the browser).



#### x-request-url



The requested URL.



#### x-final-url



The final URL, after following all redirects.



Hosting



$3



Original article



* Create a repo on GitLab or GitHub with the contents of the proxy folder.

* Create vercel.json file in the repo. It sets up Vercel hosting for the repo:



`js

{

  "version": 2,

  "name": "nodejs-mysql",

  "builds": [

    { "src": "index.js", "use": "@vercel/node" }

  ],

  "routes": [

    { "src": "/(.*)", "dest": "/index.js" }

  ]

}

`



* Push the changes to the repo.

* Login to Vercel using your GitLab or GitHub account.

* Click "Add New" → "Project".

* Choose "GitLab" or "GitHub".

* Find the repo in the list and click the "Import" button next it.

* After the project has been deployed, it will show the website URL for it. Use it as a proxy server URL. Example: https://my-cors-proxy.vercel.app?url={urlEncoded}.







Restrictions



To prevent the use of the proxy for casual browsing, the proxy requires one of the following request headers to be present:

* origin

* x-requested-with



Stats



There's a basic "stats" page available at /stats URL. It displays a list of the most recent requests to the proxy: date, time, user subnet's IP address hash (in a form of a single unicode character) and the proxied URL.



When running in a containerized environment like Vercel, the proxy instance might be stopped when it doesn't receive incoming HTTP requests and then started again when an incoming HTTP request arrives. Any stats will be naturally cleared during such restart.