I have one application on one domain that talks to another application through browser making API calls. Its getting below error in the devtools logs
CORS Allow Origin Not Matching Origin
The route it takes is through 3 servers before it hits the application which is hosted in AKS.
First it hits an nginx TLS server and here I have enabled CORS like so underneath the location block
add_header 'Access-Control-Allow-Origin' 'https://mysite.domain';
add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS, PUT, DELETE";
add_header "Access-Control-Allow-Headers" "Authorization, Content-Type";
Next it gets forwarded on to an nginx reverse proxy server which has the same config defined under the location block
Next it hits the service mesh (istio) in AKS where the virtual service it hits has the below configuration for CORS
- corsPolicy:
allowCredentials: true
allowHeaders:
- authorization
- content-type
allowMethods:
- GET
- POST
- OPTIONS
- PUT
- DELETE
allowOrigins:
- exact: '*'
If I bypass my nginx servers then I dont have any issue but when I target the service through the nginx servers I get the above CORS error. Looking at the devtool logs and the failure in detail it makes no sense as I can see the CORS policy of all three hops is identical and the access-control-allow-origin is the same for all of them and it exactly matches the Origin field in the same request.
I have tried many combinations including allowing ALL on the nginx servers like below
add_header 'Access-Control-Allow-Origin' '*';
And I also tried locking it down to the URL on the virtual service in K8S but that didnt work either
Related
Access to font at '' from origin '' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
If you control the server, then you can adjust the settings of your server Apache/Nginx or whatever to add the Access-Control-Allow-Origin header to your HTTP responses.
In your case, you probably want something like (this will allow your domain to access the fonts, but prevent other domains from using it, including your own subdomains):
Access-Control-Allow-Origin: https://www.stubwire.com
I got the Access-Control-Allow-Origin header usage from: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Here is another resource that gives examples of how to set up various servers (IIS, Nginx, Apache) to add the Access-Control-Allow-Origin header: http://support.maxcdn.com/how-to-use-cdn-with-webfonts/
I currently have an issue where I have set up a flask app with
CORS(app)
But I get every sort of COR's error as a response. This only happens in production though.
I get errors like
Access to XMLHttpRequest at 'https://example.com' from origin 'https://2e11e606fda6.ngrok.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Or
Access to XMLHttpRequest at 'https://example.com' from origin 'https://2e11e606fda6.ngrok.io' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed
I also tried diferent variations of CORS requests in the headers via nginx location / block, but that lead to some of the same sort of errors.
Any help would be appreciated.
So after a couple hours of exhausting everything. I by chance ended up looking in the nginx access log.
There it showed a error code 413
From there I was able to fix my nginx config to allow the file upload to work. So it seems that the CORS issue is not always actually about cors, but the way nginx reports errores.
I'm working on building a web application that communicates with a Laravell API through an Nginx server. I tried following the directions on the Nginx website for wide open cors, but it doesn't like the wild card response when sending credentials.
Access to fetch at 'https://api.***.com/' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '' when the request's credentials mode is 'include'.
The API server requires a Bearer access token to authenticate, and each endpoint is at its own path on the server. What is the correct way to configure Nginx in this scenario?
The error message is right, you can't use a wildcard origin and credentials:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
For requests without credentials, the literal value "*" can be specified, as a wildcard; the value tells browsers to allow requesting code from any origin to access the resource. Attempting to use the wildcard with credentials will result in an error.
Instead, just pass back the actual origin, the one that arrived in the Origin HTTP header, then it will always match:
add_header Access-Control-Allow-Origin $http_origin always;
I'm trying to make a GET request to a Context Broker instance from a browser.
I've enabled CORS on the CB using the -corsOrigin __ALL flag when starting the app, and I can see that this has worked by making a request in POSTMAN and seeing this header in the response: access-control-allow-origin →*.
I need to specify the Fiware-Service header in my GET request in order to get the correct entities, which I believe is making the request not simple, triggering an OPTIONS HTTP request.
Inspecting the outgoing request, Chrome reports that these headers are sent:
Access-Control-Request-Headers: fiware-service
Access-Control-Request-Method: GET
The response I get from the Context Broker is:
Request URL: http://xxx.xxx.xxx.xxx:1026/v2/entities/
Request Method: OPTIONS
Status Code: 405 Method Not Allowed
A previous answer by McMutton, to a similar question stated:
"do the necessary changes on your js code to make sure your request
falls within the scope of simple requests."
Which was directed at removing non-standard headers from the request. However, for me I cannot see any non-standard headers being sent.
Reading the Fiware documentation on Access-Control-Allow-Headers, there is a link to the source code where the allowed headers are specified. There, I can see the Fiware-Service header defined, but it does not case-match the headers being sent from the browser (the browser has converted my headers to all lower case).
Does anyone know if "the headers check" in the Context Broker is case-sensitive?
If not, what else could be the issue?
Edit: this issue seems to have been reported here:
https://github.com/telefonicaid/fiware-orion/issues/3453
Based in the discussion on the associated github issue it seems the problem is due to Context Broker is pretty old (version 1.7.0) and that feature wasn't developed yet in that version.
The solution is to update Context Broker to the most recent version (2.2.0 at this moment).
Thanks #fgalan, yes the feature is included in the latest Context Broker version. However, our system is currently quite fragile, so until we can confidently re-build and migrate to the newer version I'm going to mock the HTTP response for the options request using NGINX.
This configuration listens for requests on a different port to the Context Broker, and sends a success response when OPTIONS HTTP requests arrive.
If it's not an OPTIONS HTTP request, NGINX forwards the request to the Context Broker instance.
server {
listen 1885;
listen [::]:1885;
location / {
if ($request_method = OPTIONS ) {
add_header Content-Length 0;
add_header Content-Type text/plain;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Fiware-Service';
return 204;
}
proxy_pass http://xxx.xxx.xxx.xxx:1026;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
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