Purge X-CSRF-TOKEN for visitors to fix XMLHttpRequest being blocked by CORS policy - javascript

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 :)

Related

WordPress publishing failed; javascript shows errors 'Access to fetch ... has been blocked by CORS policy'

I have uploaded WordPress manually on freewebhostingarea.com using my own domain. When I create a new page in Wordpress, I get some errors in javascript console (attached image1) but it lets me add/edit content. When I try to publish the page, I get the error 'Updating failed' and javascript console gives additional errors (attached image2) as below:
"Access to fetch at 'http://e.freewebhostingarea.com/not-found.html' (redirected from 'http://www.shia-match.com/wp-json/wp/v2/pages/16/autosaves?_locale=user') from origin 'http://www.shia-match.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled."
What could I be doing wrong?
Errors when creating a new WordPress page,
Errors when trying to publish page
Just had this same problem, the cross origin (CORS) policy blocking fetching by the https:// version of a site from the https://www version.
mediaguru’s answer alerted me to check the wp-config file. I found that I had added these lines, and so removed them:
define('WP_HOME', 'https://www.example.com');
define('WP_SITEURL', 'https://www.example.com');
I then rechecked WP’s Settings > General > WordPress Address (URL) and Site Address (URL). Prior to my edit of the wp-config file, they had displayed the www URL, but greyed out and non-editable. Now they had both reverted to the non www version of the URL (and were editable).
On my (Dreamhost) server, the canonical URL is set to www. So I changed the Settings > General URLs to www and… bingo. Solved.
It sounds like you just copied your wordpress files and db from one location to another? If so, you will need to change settings in your wordpress config as well as in your database to make sure the new location is not referring to the old location's database or files.

CORS error when fetching api from its own domain

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

error int the Failed to set referrer policy

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.

XMLHttpRequest cannot load - Origin 'null' is therefore not allowed access

I am doing a login to connect through a service layer to a Linux server that has sap b1, and I get the following error.
XMLHttpRequest cannot load https://hanab1:50000/b1s/v1/Login. A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'null' is therefore not allowed access.
I find from google chrome and despite attempts, always the same error is generated, the funny thing is that when we perform the video https://www.youtube.com/watch?v=ilDH8nhnp4o,I get the error above dimensioned, but when I enter the URL directly the next line https://hanab1:50000/B1S/v1, see I have access to all information.
If anyone can help me in advance I thank you for your collaboration and interest.
In simple words, you cannot. To enable the Access Control, you need to change the way, the server sends you the headers. If your server is a PHP based one:
<?php
header("Access-Control-Allow-Origin: *");
And for SAP (if it uses Apache), the headers should be:
Header set Access-Control-Allow-Origin "*"
You can learn for other servers from here: I want to add CORS support to my server.

SEC7118: XMLHttpRequest CORS - IE Console message

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.

Categories

Resources