I have very basic question regarding the "Access-Control-Allow-Origin" header.
Assume that we have a website "www.siteA.com" that will be doing the CORS to another site "www.siteB.com" and the "Access-Control-Allow-Origin" on siteB is set as "www.siteC.com" only.
When user via browser access siteA and it tries accessing content from siteB, what will the response look like?
Will the request be blocked at the server level
or
will it send the entire response with "Access-Control-Allow-Origin" header set to "www.siteC.com" and will be blocked by user's browser? (i think the first is the correct one)
When user via browser access siteA and it tries accessing content from siteB, what will the response look like?
The same as any other response from the site.
Will the request be blocked at the server level
No. CORS is an instruction to the browser that it should not apply the Same Origin Policy to the request. The server can't (reliably) tell where a request came from to block it at the server level.
will it send the entire response with "Access-Control-Allow-Origin" header set to "www.siteC.com" and will be blocked by user's browser?
Yes.
will be blocked by user's browser?
Yes, because only www.siteC.com domain can access the resource according to your Access-Control-Allow-Origin header. They would send back;
Access-Control-Allow-Origin: http://www.siteC.com
You can find answers the questions about the Access-Control-Allow-Origin header via this.
Related
I noticed an issue after deploying to Netlify, chrome was blocking my ajax requests to a public Apple api, but it was working for the friends I sent a link to.
Now it's broken in the opposite direction. It seems like the header is my netlify url rather than localhost in development.
Access to fetch at 'https://itunes.apple.com/search?entity=podcast&term=test&limit=6'
from origin
'http://localhost:3001' has been blocked by CORS policy: The 'Access-Control-Allow-Origin'
header has a value 'https://effulgent-dingus-192e6.netlify.app'
that is not equal to the supplied origin. Have the server send the header with a valid value,
or, if an opaque response serves your needs, set the request's mode to 'no-cors'
to fetch the resource with CORS disabled.
How can I make sure the Access-Control-Allow-Origin isn't cached (or fix whatever the problem is).
I found that NextJS was running the API call on the server side as well as the intended client side. I wrapped the call in a check to see if window !== undefined to do the call client side only. I think this has fixed it.
To prevent caching, include a Vary: Origin header in the response.
CORS and caching
Suppose the server sends a response with an Access-Control-Allow-Origin value with an explicit origin (rather than the "*" wildcard). In that case, the response should also include a Vary response header with the value Origin — to indicate to browsers that server responses can differ based on the value of the Origin request header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin#cors_and_caching
when i post the data using POST method in woocommerce api. i am getting cors issue
Access to fetch at 'http://localhost/wordpress/wc-api/v3/customers?oauth_consumer_key=ck_64d88e1fa3516e9f5a06b6053f02976a534d3f8f&oauth_nonce=zsu3ysEnFHhvrZt4Nc7H66Dgu28H20K7&oauth_signature_method=HMAC-SHA256&oauth_timestamp=1562587817&oauth_version=1.0&oauth_signature=KtFxvyQNklUlfCi6rNWyJ0DEJ6AS2ZbwbO44u%2FEqxG4%3D' from origin 'http://localhost:8100' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
You have to set a Access-Control-Allow-Origin header on each request to the server, if your server is on a different domain than the app on which you are making those requests (the server sets it as a response header). Adding that header tells the system that the external domain "localhost:8100" is allowed to make those requests.
You cannot circumvent this requirement in vanilla browsers, because it is a built in security feature to reduce CORS attacks
PS. different ports on the same domain are considered to be different domains. Thus example.com will get a 401 error, if you are making a request to example.com:8100. Same goes for localhost, or any other domain.
Example code from an Apache2 web server .conf file, that I personally use to set these headers.
SetEnvIf Origin "^http(s)?://(.+\.)?(staging.\xxx\.com|xxx\.com|xxx\.local|xxx\.local:4200|a2\.local)$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
Just replace the xxx.com domains with localhost:8100 or whatever else you need in that array. (if you are using Apache web server)
As a result, the Chrome network tab should have an Access-Control-Allow-Origin header on attached to the request
I'm using Restangular. I would like to get full response so I set
Restangular.setFullResponse(true);
but then I discovered that my custom headers does not work. Documentation for setFullResponse() method says:
in order for Restangular to access custom HTTP headers, your server must respond having the Access-Control-Expose-Headers: set.
I would like to send my custom headers but I don't want to change server settings. Is it possible?
If I leave default settings i.e.setFullResponse(false) there is no issue with custom headers. Is there another solution except changing server settings?
The sentence you cite from the setFullResponse() docs is about what headers from the response your Restangular app will be able to access. And what that is saying is, it’s not possible to access most of the headers from the response unless the server’s already configured to send the right response-header names in the Access-Control-Expose-Headers header.
Without the server setting any value for that header, the only response headers that browsers will let you access from client-side JavaScript in your web app are the Cache-Control,
Content-Language,
Content-Type,
Expires,
Last-Modified
&
Pragma response headers.
See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name for the spec on that.
I would like to send my custom headers but I don't want to change server settings. Is it possible?
If you mean you want to send custom headers in a request from your client-side Restangular code to the server, please provide more details about exactly which custom headers you want to send.
There too though, there’s another CORS header your server must send in the response: the Access-Control-Allow-Headers response header. If the server isn’t configured to send that with the right header names listed, then your request will fail. The reason in that case is, you will hit https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests.
We have a site where we are using cookies for tracking purposes. Now we are thinking in changing the domain of our site but we will want to still recognise User's sessions from the old domain. Is this possible?
You can't retrieve cookies that belong to other domains. As a workaround (in case you can still use the old domain); by creating an iframe inside http://newdomain.com from http://olddomain.com, you can get cookies and send to parent via postMessage.
Cookies are affected by same origin policy but you can bypass it with CORS (Cross-origin resource sharing).
CORS is a play between browser and server.
Basic idea is allow ajax request to cross domains but you can use to share cookies(security measures should be taken).
Browser send a request with Origin header.
If the server allows the request then it reply with Access-Control-Allow-Origin header with the value of origin.
If the server doesn’t reply with the header or don’t match Origin with Access-Control-Allow-Origin browser disallow the request.
But it doesn’t send cookies or something like that by default(you have to add “allow-credentials” extra header).
With CORS you can share the session between domains adding to new domain server the following headers:
Access-Control-Allow-Origin: https://original-domain.com
Access-Control-Allow-Credentials: true
More info about CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
http://quickleft.com/blog/cookies-with-my-cors
Premise:
When an site (http://example.com) tries to make a cross-origin request, the browser will send an HTTP request to the cross-origin server (http://other-server.com) with the header Origin: http://example.com. If the server at http://other-server.com approves http://example.com as a valid origin, then it will 1) Respond without error AND 2) set the response header to Access-control-allow-origin: http://example.com
My question is - why is it necessary to set the Access-control-allow-origin header in the response? Doesn't responding without error already acknowledge that the server (http://other-server.com) is allowing the cross-origin request?
This extra layer of acknowledgement gives servers a lot of flexibility over how they support CORS. For example:
1) A server has a lot of choices when setting the Access-Control-Allow-Origin header. It can use the * value to allow all clients, or it can limit the scope of clients by using the actual value of the origin (e.g. http://example.com). If a server does support CORS, but not for all origins, it could respond without error, but the Access-Control-Allow-Origin could be set to http://notyourorigin.com.
2) CORS allows even more flexibility via the Access-Control-Allow-Methods and Access-Control-Allow-Headers preflight response headers. These headers go beyond the simple binary success/error HTTP status, and provide more nuanced information about what is and is not supported in the server.
As the examples above point out, an error response without any context can be very confusing to the user. If you make a CORS request, and all you get back is an error response, you have no idea why that request failed. Are you doing the request wrong? Does the server support CORS at all? This can be very difficult to figure out without any accompanying information. The Access-Control-* gives more context to the user so they can effectively debug their CORS requests.