setHeaders doesn't seem to change response header

[chrisdobler]

I've been trying many different combinations of setHeaders, but am unable to make any modifications to the response header. As a test I am trying this:

const app = cors_proxy.createServer({
  originWhitelist: [], // Allow all origins
  requireHeader: ['origin', 'x-requested-with'],
  setHeaders: {
    "access-control-expose-headers" : "content-type,transfer-encoding,x-powered-by,connection,access-control-allow-origin,cache-control,date,expires,login-required,p3p,pragma,server,x-frame-options,x-cache,via,x-amz-cf-id,Access-Control-Allow-Credentials,x-final-url",
    "Access-Control-Allow-Credentials": "true",
    "x-powered-by": "CORS Anywhere",
    "access-control-allow-origin": "localhost"
  },
});

None of these headers become attached. Also require header does work fine.

[chrisdobler]

I see you can set response headers using the key 'setResponseHeaders', using this fork:

git://github.com/PropellerAero/cors-anywhere.git#9f95b03c7f47317eea59455a131642c89e243557

[Rob--W]

What's your real use case for wanting to override the response headers?

The PR at #52 has been abandoned, but if a new PR comes in I am willing to accept it given a good use case.

[chrisdobler]

For the project I'm working on we needed to be able to set the correct cors for credentials. It works great now. I'll try to reopen the pr if I can. Thanks!

[Rob--W]

For the project I'm working on we needed to be able to set the correct cors for credentials. It works great now. I'll try to reopen the pr if I can. Thanks!

I've wrote it many times, and I will state it again: Credentials should not be enabled for the proxy if it can proxy requests to multiple different domains. Otherwise credentials may be leaked across domains.

[chrisdobler]

leaking the cookies from www.thesite.local -> localhost is specifically the point. this is a local proxy for a dev env. sometimes you need to do this so that you can scrape a legacy platform in dev to avoid cors issues. Good to warn folks though.

[musikele]

Hi, I have the same problem, and I franky don't understand if it has been solved or not. This is my configuration:

cors_proxy.createServer({
    originWhitelist: [], // Allow all origins
    requireHeader: ['origin', 'x-requested-with'],
    setHeaders  : {
        "access-control-allow-origin": "localhost"
    }
})
.listen(port, host, function() {
    console.log('Running CORS Anywhere on ' + host + ':' + port);
});

As you see, I'm using "setHeaders" to change the header access-control-allow-origin.

But I still see access-control-allow-origin: * in the response. Why?

[Rob--W]

First, the setHeaders option sets request headers, not response headers.

Secondly, you are not supposed to touch Access-Control-Allow-Origin, because that is handled by CORS Anywhere. The logic responsible for setting Access-Control-Allow-Origin: * is at: https://github.com/Rob--W/cors-anywhere/blob/2ee31471ce3b624b5503bcc9c62fbe6783192c45/lib/cors-anywhere.js#L53

[musikele]

It might seem stupid, but my browsers are blocking Access-Control-Allow-Origin: * because i use fetch with credentials: true so the browser worries that I send cookies to the wrong domain.

That's right, it's stupid, but that' exactly what I want to do because I'm a developer and I need to do this to develop ... In production it will not be like this ...

However, I changed the code of withCORS and now I'm working

[chrisdobler]

@musikele - like Rob said headers is for request. Use the fork i referenced above if you need more customization. It includes the ability to set responseHeaders as well as request headers.

[dotbloup]

@musikele @chrisdobler You can hard code the value of Access-Control-Allow-Origin of response headers: at /lib/cors-anywhere.js For sure, no browsers (chrome, firefox, safari, Edge) accept Access-Control-Allow-Origin: * as in the HTTP response headers. In Browser, we should an error like: "CORS not valid: url not matching: missing"

Access-Control-Allow-Origin: url should be equal to Origin: url from HTTP request headers, otherwise it creates an error like HTTP request header => Origin: http://yourURL.com HTTP response header => Access-Control-Allow-Origin: http://yourURL.com

Furthermore, other CORS response headers can mess up the system and return 403. That's why any other response like X-CORS-request- should be deleted from response headers. For instance, a URL send CORS-request- and it will forwarded by cors-anywhere and it will fail in the browser. So it would be nice if cors-anywhere could remove the response headers like X-CORS-request-* from url like this one: http://www.dpbolvw.net/click-7705052-13093412

[Rob--W]

@dotbloup

For sure, no browsers (chrome, firefox, safari, Edge) accept Access-Control-Allow-Origin: * as in the HTTP response headers.

This statement is incorrect, because Access-Control-Allow-Origin: * is accepted, provided that the request is not using credentials:

• withCredentials should false in XMLHttpRequest (default).
• credentials should be omit in fetch (default)
• The Access-Control-Allow-Credentials response header should NOT be true.

[ondrek]

Omg, just add setResponseHeaders for any header we want to add. It's a developer package. I can't use the package for the same reason.

[Rob--W]

@ondrek See https://github.com/Rob--W/cors-anywhere/issues/102#issuecomment-355933612

What's your real use case for wanting to override the response headers?

(...) if a new PR comes in I am willing to accept it given a good use case.

[fivitti]

Hi! I have an use case. I have a cache solution and I control it using cache headers (Cache-Control, Expires). I need a possibility to add headers to response to handle it.

// It will be useful
setResponseHeaders: { 'cache-control': 'max-age=30' }

[Rob--W]

@fivitti The client can use fetch with cache to force certain caching behavior regardless of the response header: https://developer.mozilla.org/en-US/docs/Web/API/Request/cache

[MANDA-LAWINE]

If anyone still has this problem, check this fork https://github.com/MANDA-LAWINE/cors-anywhere, Just add setResponseHeaders to createServer options.

[vankeer]

@MANDA-LAWINE thank you for providing this fork. @Rob--W I don't understand why you don't want to add this setResponseHeaders option? Its implementation is very straightforward and it's another useful feature to have for a number of cases hinted at above. I'm having a similar use case now where I would like to modify and add response headers, so I'll have to rely on the fork for now.

[Rob--W]

@Rob--W I don't understand why you don't want to add this setResponseHeaders option? Its implementation is very straightforward and it's another useful feature to have for a number of cases hinted at above. I'm having a similar use case now where I would like to modify and add response headers, so I'll have to rely on the fork for now.

I am willing to accept a PR with the setResponseHeaders option if a good use case is given.

The initial report here starts with an example of setting CORS headers, which would break the core functionality of this library (CORS Anywhere manages the selection of the response headers to get CORS to work correctly). Another person asked for caching behavior, and I suggested a client-side API to get the desired functionality independent of the server.

[0alfa]

a use case:

cross-origin-resource-policy: same-origin could be set to: cross-origin-resource-policy: cross-origin

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy