cors-anywhere: setHeaders doesn't seem to change response header
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.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 1
- Comments: 19 (7 by maintainers)
First, the
setHeadersoption 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 settingAccess-Control-Allow-Origin: *is at: https://github.com/Rob--W/cors-anywhere/blob/2ee31471ce3b624b5503bcc9c62fbe6783192c45/lib/cors-anywhere.js#L53Omg, just add
setResponseHeadersfor any header we want to add. It’s a developer package. I can’t use the package for the same reason.It might seem stupid, but my browsers are blocking
Access-Control-Allow-Origin: *because i use fetch withcredentials: trueso 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
withCORSand now I’m workingIf anyone still has this problem, check this fork https://github.com/MANDA-LAWINE/cors-anywhere, Just add setResponseHeaders to createServer options.
@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.
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.