I am using CORS POST request with everything taken care as given #http://www.html5rocks.com/en/tutorials/cors/
Server sets Response header to:
'Access-Control-Allow-Origin':'*' and I can see this header value in IE developer tool.
But on IE10 browser I see console message as "SEC7118: XMLHttpRequest for http:// required Cross Origin Resource Sharing (CORS).
When I check on Microsoft site it has below given explanation.
http://msdn.microsoft.com/en-us/ie/dn423949(v=vs.94).aspx
SEC7118
Description:
"XMLHttpRequest for [URL] required Cross Origin Resource Sharing (CORS). "
An XMLHttpRequest was made to a domain that was different than your page's domain. This requires the server to return an "Access-Control-Allow-Origin" header in its response headers, but one was not returned.
Suggested Fix:
The server must support CORS requests and return an appropriate "Access-Control-Allow-Origin" header with the resource. See CORS for XHR in IE10 for more info about CORS in response headers.
Questions:
I want to know if this console message is an ERROR ??
Will this cause any failures ??
Why do I get this message even after setting response header 'Access-Control-Allow-Origin' value to '*'??
Does 'Access-Control-Allow-Origin' value has to be origin name for
IE10 to work? I know * is not a very good option, But does IE
requires exact origin name ??
I kept URL's and cookie details hidden from these images.
From MSDN:
Security error codes are in the form SEC7xxx [In IE]
Pertaining to SEC7118:
An XMLHttpRequest was made to a domain that was different than your page's domain. This requires the server to return an "Access-Control-Allow-Origin" header in its response headers, but one was not returned.
Note This error code was removed in IE11 on Windows 10. It remains in IE11 for Windows 8.1 and Windows 7.
So it is technically viewed as an error from IE's perspective, but certainly isn't one (hence why it is going away). Access-Control-Allow-Origin is set on a resource, but isn't necessarily sent back with the request. If a specified resource DOESN'T have Access-Control-Allow-Origin:* (or a domain), the resource would not be accessible and the server would likely return a 503 or 404 and you would see a true error message in the console similar to the below:
XMLHttpRequest cannot load http://example.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://blog.example.com' is therefore not allowed access.
I encountered SEC7118 when CORS was set up correctly. I verified that the requests were completing with status 200 using the network debugger. So, you can disregard this message if your application is otherwise functioning properly.
I have seen this error in IE11:
SEC7118: XMLHttpRequest for http:// required Cross Origin Resource Sharing (CORS)
Adding the following to my .htaccess fixed it:
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
<FilesMatch "\.(cur|gif|ico|jpe?g|png|svgz?|webp)$">
SetEnvIf Origin ":" IS_CORS
Header set Access-Control-Allow-Origin "*" env=IS_CORS
</FilesMatch>
</IfModule>
</IfModule>
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image
I had this same issue. It has to do with Internet Explorer's handing of third party cookies. You can fix this issue by going into Tools>Internet Options then selecting the Privacy tab. If you change the setting to "Accept All Cookies" you will no longer see that message.
The safer way to do this would be to click on the "Sites" button and allow cookies from your site's url.
Related
I've just switched over a website from one host to a different host and for some reason we're getting multiple of the following errors when trying to access a third party API
Access to XMLHttpRequest at 'https://externalwebsite.com/api/' from origin 'https://www.mainwebsite.com.au' has been blocked by CORS policy: Request header field x-xsrf-token is not allowed by Access-Control-Allow-Headers in preflight response.
The .htaccess file has a CORS policy to allow these connections:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
I can see the old host has set the following cookies, which when I deleted them on my system it allowed the website to work normally:
XSRF-TOKEN 1551054855|ZxDIR_16hNnw .www.mainwebsite.com
hs 1333923782 .www.mainwebsite.com
svSession 253f275579e7747b6495ca6ff45ba024da3bd3b36906f5ac14b709de48792403faf1d3bbff2205d92d2e9a8de90d4b101e60994d53964e647acf411e4f798bcd4c6094311de4bdfbf81f1c6cdfaa3e9de1f5fc736f232b0c584f30f1f7d232d9 .www.mainwebsite.com
How can I include some PHP or Javascript to purge those cookies for anyone who loads the website so that it loads normally for those that have visited the website in the past?
If you can give me some more info of your front end framework I will explain it more clearly.
Possible solution : on page load add script to remove cookies
$(window).load(function() {
$.cookies.del('name_of_your_cookie');
});
This will remove cookies now just add a read cookie command and a condition that will check if cookies are old and need to be removed.
you can use document.cookie to read cookies and parse to check for key values.
Ping me in case of any query :)
One of app users constantly has an error when trying to fetch api from the same domain. This error occurs in Chrome only, other browsers are OK at his computer. He also tried to install Chrome CORS extention, but no luck. Does anybody has any idea why this might happen?
Error text below:
Failed to load http://my-app.com/api/v1/scoreboard: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.my-app.com' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
If www and non www causing the problems of CORS. Then in my opinion you can set redirection of non WWW URL to WWW URL. It can be achieved using .htaccess or changing some settings on c-panel
Here the related answer Redirect non-www to www in .htaccess
Another option is to set cors headers on server side.
Hope it helps
This depends on several things but usually calling code should not have any special configuration. instead your server side must decide to reject or allow the request. in case you can have a .htaccess file on your server side try to add this lines.
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods: "GET,POST,OPTIONS,DELETE,PUT,PATCH"
Header set Access-Control-Allow-Headers "Content-Type,Authorization"
</IfModule>
Do not forget to add OPTIONS method in your allowed method list. Thats because the browser always checks the end-point availability by sending an OPTIONS request.
Adding 301 redirect from www to no-www domain name worked for me. Found solution here Nginx no-www to www and www to no-www
I have seen this problem quite a few times and it pops up time and again. This is a CORS(i.e. Cross origin request issue).The exact error I got this time is as follows:
XMLHttpRequest cannot load
https://myURL/myappdomain.subdomain.qual1/$count. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response had HTTP status code 401.
Following are the possible solutions I have worked out in past. But they dont always work. They are URL specific solutions:
1) Having CORS plugin on chrome installed
2) Disabling web security from command line "--disable-web-security"
3) using 'jsonp' as format instead of 'json'
4) toggling cross-origin to "true" or "false".
Questions I need answer for
1) Why do we get this error? Is it something that the Server is imposing on the client pages?
2) What is the safest way to solve this? i.e. The method in which there is not security vulnerability and a reliable method.
3) Why cors is never an issue for API calls made from within nodeJS code?
According to CORS specification (7.1.7 - Redirect Steps (for Simple Cross-Origin Request)):
If the request URL origin is not same origin with the original URL origin, set source origin to a globally unique identifier (becomes "null" when transmitted).
I have a scenario where javascript from a.blah.com makes a CORS request (i.e. Origin request header present) by sending browser to b.blah.com, which responds with a 302 and location = c.blah.com. If I am reading the spec correctly, this should result in the request to c.blah.com containing Origin header = "null". Instead, the Origin header is not present and thus the request to c.blah.com is not considered a CORS request.
The above behavior was experienced in Chrome 54. I have not confirmed the exact request contents in other browsers, but I have checked that my particular application flow works in Chrome 54, Firefox 37, and IE 11 browsers, which implies they never see Origin header set to "null" (my services will fail requests loudly if the receive an Origin = "null").
This all worries me because while my application is working, it actually shouldn't be, and I don't want to just ignore this fact. Am I misunderstanding the spec? Are there any caveats to the spec behavior that I've missed?
All traffic is HTTPS, not returning * (wildcard) in CORS response header, setting with-credentials flags/headers as appropriate, no proxies in use, all actors on separate machines so should not be a localhost gotcha...
Thanks.
In my original configuration, the request to b.blah.com was a form posted by js (not xhr). After some digging around, it seems that since the request was triggered by js, that warranted an Origin header on the request to b.blah.com, but the resulting redirect to c.blah.com was handled by the browser without any script/xhr intervention, so the redirect was not decorated with an Origin header.
I set up a test where the request to b.blah.com was xhr, and that did cause an Origin = "null" on the redirect to c.blah.com.
I suppose I need to better research the nuances of when same-origin policy is enforced.
Thanks.
I'm getting the following error in my chrome console for a Wordpress site I'm working on.
Failed to set referrer policy: The
value 'http://example.com/comic/' is not one of 'always', 'default',
'never', 'no-referrer', 'no-referrer-when-downgrade', 'origin',
'origin-when-crossorigin', or 'unsafe-url'. The referrer policy has
been left unchanged.
It's reffereing to this line in the <head> of the HTML document...
<meta name="Referrer" content="http://example.com/comic/" />
I'm vieing the page over http, not https.
What is causing this issue and how can I fix it?
Go into your .htaccess file and change the following:
Header set Referrer-Policy ""
to
Header set Referrer-Policy "origin"
That should fix the issue.
The reason is more than likely because you don’t have correct permissions on your .htaccess file that allows w3tc to make the changes it needs to.
Here 's the definition taken from the specs:
A referrer policy modifies the algorithm used to populate the Referer header when fetching subresources, prefetching, or performing navigations.
Every environment settings object has an algorithm for obtaining a referrer policy, which is used by default for all requests with that environment settings object as their request client.
Therefore Referral policy deals with what information (related to the url) the browser ships to a server to retrieve an external resource.
The options for the content attribute listed in the specs are :
no-referrer which specifies that no referrer information is to be sent along with requests made from a particular request client to any origin. The header will be omitted entirely.
no-referrer-when-downgrade doesn't send Referrer header to non priori authenticated url (if an https url links to an http url no header is sent)
same-origin policy specifies that a full URL, stripped for use as a referrer, is sent as referrer information when making same-origin requests from a particular request client. while Cross-origin requests won't contain referrer information.
origin sends the scheme, host, and port (basically, the subdomain) stripped of the full URL as a referrer, i.e. https://moz.com/example.html would simply send https://moz.com for all.
origin-when-cross-origin sends the format described in origin to cross-origin, while a full stripped URL is sent to same origin requests.
unsafe-url policy specifies that a full URL, stripped for use as a referrer, is sent along with both cross-origin requests and same-origin requests made from a particular request client.
it's unsafe because it will leak origins and paths from TLS-protected resources to insecure origins.
The empty string "" corresponds to no referrer policy, causing a fallback to a referrer policy defined elsewhere, or in the case where no such higher-level policy is available, defaulting to no-referrer-when-downgrade.
always behaves like unsafe-url.
you can manually find and change as following in .htaccess file :
<IfModule mod_headers.c>
Header set Referrer-Policy ""
</IfModule>
to
<IfModule mod_headers.c>
Header set Referrer-Policy "origin"
</IfModule>
Chrome Inspection Console showed me the same Error for my Wordpress sites which have W3 Total Cache installed.
"Failed to set referrer policy: The value '' is not one of 'no-referrer', 'no-referrer-
when-downgrade', 'origin', 'origin-when-cross-origin'"
and I tried to update the .htaccess file as indicated in the above answer. This fixed the Chrome Inspection Console error but it returned a few moments later.
Checking the Dashboard of W3 Total Cache Performance ->Browser Cache-> Referrer Policy-> Directive, this entry was showing blank.
Selecting 'origin' from the dropdown resulted in .htaccess being updated with the same value 'origin'
"Referer" as a header is spelled without the double R. Maybe with the double R, it's matching against a different header than the one you mean.
In my case, www. was missing in the API URL, while www. was present on the form page. Just ensure your API URL has www. if your page has it too.