I have called third party API using Jquery AJAX. I am getting following error in console:
Cross-Origin Read Blocking (CORB) blocked cross-origin response MY URL with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
I have used following code for Ajax call :
$.ajax({
type: 'GET',
url: My Url,
contentType: 'application/json',
dataType:'jsonp',
responseType:'application/json',
xhrFields: {
withCredentials: false
},
headers: {
'Access-Control-Allow-Credentials' : true,
'Access-Control-Allow-Origin':'*',
'Access-Control-Allow-Methods':'GET',
'Access-Control-Allow-Headers':'application/json',
},
success: function(data) {
console.log(data);
},
error: function(error) {
console.log("FAIL....=================");
}
});
When I checked in Fiddler, I have got the data in response but not in Ajax success method.
Please help me out.
dataType:'jsonp',
You are making a JSONP request, but the server is responding with JSON.
The browser is refusing to try to treat the JSON as JSONP because it would be a security risk. (If the browser did try to treat the JSON as JSONP then it would, at best, fail).
See this question for more details on what JSONP is. Note that is a nasty hack to work around the Same Origin Policy that was used before CORS was available. CORS is a much cleaner, safer, and more powerful solution to the problem.
It looks like you are trying to make a cross-origin request and are throwing everything you can think of at it in one massive pile of conflicting instructions.
You need to understand how the Same Origin policy works.
See this question for an in-depth guide.
Now a few notes about your code:
contentType: 'application/json',
This is ignored when you use JSONP
You are making a GET request. There is no request body to describe the type of.
This will make a cross-origin request non-simple, meaning that as well as basic CORS permissions, you also need to deal with a pre-flight.
Remove that.
dataType:'jsonp',
The server is not responding with JSONP.
Remove this. (You could make the server respond with JSONP instead, but CORS is better).
responseType:'application/json',
This is not an option supported by jQuery.ajax. Remove this.
xhrFields: {
withCredentials: false },
This is the default. Unless you are setting it to true with ajaxSetup, remove this.
headers: {
'Access-Control-Allow-Credentials' : true,
'Access-Control-Allow-Origin':'*',
'Access-Control-Allow-Methods':'GET',
'Access-Control-Allow-Headers':'application/json',
},
These are response headers. They belong on the response, not the request.
This will make a cross-origin request non-simple, meaning that as well as basic CORS permissions, you also need to deal with a pre-flight.
In most cases, the blocked response should not affect the web page's behavior and the CORB error message can be safely ignored. For example, the warning may occur in cases when the body of the blocked response was empty already, or when the response was going to be delivered to a context that can't handle it (e.g., a HTML document such as a 404 error page being delivered to an tag).
https://www.chromium.org/Home/chromium-security/corb-for-developers
I had to clean my browser's cache, I was reading in this link, that, if the request get a empty response, we get this warning error. I was getting some CORS on my request, and so the response of this request got empty, All I had to do was clear the browser's cache, and the CORS got away. I was receiving CORS because the chrome had saved the PORT number on the cache, The server would just accept localhost:3010 and I was doing localhost:3002, because of the cache.
Return response with header 'Access-Control-Allow-Origin:*'
Check below code for the Php server response.
<?php header('Access-Control-Allow-Origin: *');
header('Content-Type: application/json');
echo json_encode($phparray);
You have to add CORS on the server side:
If you are using nodeJS then:
First you need to install cors by using below command :
npm install cors --save
Now add the following code to your app starting file like ( app.js or server.js)
var express = require('express');
var app = express();
var cors = require('cors');
var bodyParser = require('body-parser');
//enables cors
app.use(cors({
'allowedHeaders': ['sessionId', 'Content-Type'],
'exposedHeaders': ['sessionId'],
'origin': '*',
'methods': 'GET,HEAD,PUT,PATCH,POST,DELETE',
'preflightContinue': false
}));
require('./router/index')(app);
It's not clear from the question, but assuming this is something happening on a development or test client, and given that you are already using Fiddler you can have Fiddler respond with an allow response:
Select the problem request in Fiddler
Open the AutoResponder tab
Click Add Rule and edit the rule to:
Method:OPTIONS server url here, e.g. Method:OPTIONS http://localhost
*CORSPreflightAllow
Check Unmatched requests passthrough
Check Enable Rules
A couple notes:
Obviously this is only a solution for development/testing where it isn't possible/practical to modify the API service
Check that any agreements you have with the third-party API provider allow you to do this
As others have noted, this is part of how CORS works, and eventually the header will need to be set on the API server. If you control that server, you can set the headers yourself. In this case since it is a third party service, I can only assume they have some mechanism via which you are able to provide them with the URL of the originating site and they will update their service accordingly to respond with the correct headers.
If you are working on localhost, try this, this one the only extension and method that worked for me (Angular, only javascript, no php)
https://chrome.google.com/webstore/detail/moesif-orign-cors-changer/digfbfaphojjndkpccljibejjbppifbc/related?hl=en
In a Chrome extension, you can use
chrome.webRequest.onHeadersReceived.addListener
to rewrite the server response headers. You can either replace an existing header or add an additional header. This is the header you want:
Access-Control-Allow-Origin: *
https://developers.chrome.com/extensions/webRequest#event-onHeadersReceived
I was stuck on CORB issues, and this fixed it for me.
have you tried changing the dataType in your ajax request from jsonp to json? that fixed it in my case.
There is an edge case worth mentioning in this context: Chrome (some versions, at least) checks CORS preflights using the algorithm set up for CORB. IMO, this is a bit silly because preflights don't seem to affect the CORB threat model, and CORB seems designed to be orthogonal to CORS. Also, the body of a CORS preflight is not accessible, so there is no negative consequence just an irritating warning.
Anyway, check that your CORS preflight responses (OPTIONS method responses) don't have a body (204). An empty 200 with content type application/octet-stream and length zero worked well here too.
You can confirm if this is the case you are hitting by counting CORB warnings vs. OPTIONS responses with a message body.
It seems that this warning occured when sending an empty response with a 200.
This configuration in my .htaccess display the warning on Chrome:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST,GET,HEAD,OPTIONS,PUT,DELETE"
Header always set Access-Control-Allow-Headers "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Authorization"
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]
But changing the last line to
RewriteRule .* / [R=204,L]
resolve the issue!
I have a similar problem. My case is because the contentType of server response is application/json, rather than text/javascript.
So, I solve it from my server (spring mvc):
// http://127.0.0.1:8080/jsonp/test?callback=json_123456
#GetMapping(value = "/test")
public void testJsonp(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse,
#RequestParam(value = "callback", required = false) String callback) throws IOException {
JSONObject json = new JSONObject();
json.put("a", 1);
json.put("b", "test");
String dataString = json.toJSONString();
if (StringUtils.isBlank(callback)) {
httpServletResponse.setContentType("application/json; charset=UTF-8");
httpServletResponse.getWriter().print(dataString);
} else {
// important: contentType must be text/javascript
httpServletResponse.setContentType("text/javascript; charset=UTF-8");
dataString = callback + "(" + dataString + ")";
httpServletResponse.getWriter().print(dataString);
}
}
Response headers are generally set on the server. Set 'Access-Control-Allow-Headers' to 'Content-Type' on server side
I had the same problem with my Chrome extension. When I tried to add to my manifest "content_scripts" option this part:
//{
// "matches": [ "<all_urls>" ],
// "css": [ "myStyles.css" ],
// "js": [ "test.js" ]
//}
And I remove the other part from my manifest "permissons":
"https://*/"
Only when I delete it CORB on one of my XHR reqest disappare.
Worst of all that there are few XHR reqest in my code and only one of them start to get CORB error (why CORB do not appare on other XHR I do not know; why manifest changes coused this error I do not know). That's why I inspected the entire code again and again by few hours and lost a lot of time.
I encountered this problem because the format of the jsonp response from the server is wrong. The incorrect response is as follows.
callback(["apple", "peach"])
The problem is, the object inside callback should be a correct json object, instead of a json array. So I modified some server code and changed its format:
callback({"fruit": ["apple", "peach"]})
The browser happily accepted the response after the modification.
Try to install "Moesif CORS" extension if you are facing issue in google chrome. As it is cross origin request, so chrome is not accepting a response even when the response status code is 200
I attempt to send a GET request in a jQuery AJAX request.
$.ajax({
type: 'GET',
url: /* <the link as string> */,
dataType: 'text/html',
success: function() { alert("Success"); },
error: function() { alert("Error"); },
});
However, whatever I've tried, I got XMLHttpRequest cannot load <page>. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:7776' is therefore not allowed access.
I tried everything, from adding header : {} definitions to the AJAX request to setting dataType to JSONP, or even text/plain, using simple AJAX instead of jQuery, even downloading a plugin that enables CORS - but nothing could help.
And the same happens if I attempt to reach any other sites.
Any ideas for a proper and simple solution? Is there any at all?
This is by design. You can't make an arbitrary HTTP request to another server using XMLHttpRequest unless that server allows it by putting out an Access-Control-Allow-Origin header for the requesting host.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
You could retrieve it in a script tag (there isn't the same restriction on scripts and images and stylesheets), but unless the content returned is a script, it won't do you much good.
Here's a tutorial on CORS:
http://www.bennadel.com/blog/2327-cross-origin-resource-sharing-cors-ajax-requests-between-jquery-and-node-js.htm
This is all done to protect the end user. Assuming that an image is actually an image, a stylesheet is just a stylesheet and a script is just a script, requesting those resources from another server can't really do any harm.
But in general, cross-origin requests can do really bad things. Say that you, Zoltan, are using coolsharks.com. Say also that you are logged into mybank.com and there is a cookie for mybank.com in your browser. Now, suppose that coolsharks.com sends an AJAX request to mybank.com, asking to transfer all your money into another account. Because you have a mybank.com cookie stored, they successfully complete the request. And all of this happens without your knowledge, because no page reload occurred. This is the danger of allowing general cross-site AJAX requests.
If you want to perform cross-site requests, you have two options:
Get the server you are making the request to to either
a. Admit you by putting out a Access-Control-Allow-Origin header that includes you (or *)
b. Provide you with a JSONP API.
or
Write your own browser that doesn't follow the standards and has no restrictions.
In (1), you must have the cooperation of the server you are making requests to, and in (2), you must have control over the end user's browser. If you can't fulfill (1) or (2), you're pretty much out of luck.
However, there is a third option (pointed out by charlietfl). You can make the request from a server that you do control and then pass the result back to your page. E.g.
<script>
$.ajax({
type: 'GET',
url: '/proxyAjax.php?url=http%3A%2F%2Fstackoverflow.com%2F10m',
dataType: 'text/html',
success: function() { alert("Success"); },
error: function() { alert("Error"); }
});
</script>
And then on your server, at its most simple:
<?php
// proxyAjax.php
// ... validation of params
// and checking of url against whitelist would happen here ...
// assume that $url now contains "http://stackoverflow.com/10m"
echo file_get_contents($url);
Of course, this method may run into other issues:
Does the site you are a proxy for require the correct referrer or a certain IP address?
Do cookies need to be passed through to the target server?
Does your whitelist sufficiently protect you from making arbitrary requests?
Which headers (e.g. modify time, etc) will you be passing back to the browser as your server received them and which ones will you omit or change?
Will your server be implicated as having made a request that was unlawful (since you are acting as a proxy)?
I'm sure there are others. But if none of those issues prevent it, this third method could work quite well.
you can ask the developers of that domain if they would set the appropriate header for you, this restriction is only for javascript, basically you can request the ressource from your server with php or whatever and the javascript requests the data from your domain then
Old question, but I'm not seeing this solution, which worked for me, anywhere. So hoping this can be helpful for someone.
First, remember that it makes no sense to try modifying the headers of the request to get around a cross-origin resource request. If that were all it took, it would be easy for malicious users to then circumvent this security measure.
Cross-origin requests in this context are only possible if the partner site's server allows it through their response headers.
I got this to work in Django without any CORS middleware by setting the following headers on the response:
response["Access-Control-Allow-Origin"] = "requesting_site.com"
response["Access-Control-Allow-Methods"] = "GET"
response["Access-Control-Allow-Headers"] = "requesting_site.com"
Most answers on here seem to mention the first one, but not the second two. I've just confirmed they are all required. You'll want to modify as needed for your framework or request method (GET, POST, OPTION).
p.s. You can try "*" instead of "requesting_site.com" for initial development just to get it working, but it would be a security hole to allow every site access. Once working, you can restrict it for your requesting site only to make sure you don't have any formatting typos.
I'm trying to implement some code that will allow me to have one sub-domain communicate with another sub-domain, e.g. one.example.com and two.example.com. The two sites have the ability to share cookies and session data as I have set the cookie to use .example.com.
When I visit either site via standard HTTP I can dump the session and see the expected data. However if I do this via JavaScript with jQuery $.ajax() the dumped session data is empty. In both cases I use PHP to dump the session data.
I have tried the following solution but to no luck yet (http://forum.kohanaframework.org/discussion/9895/problem-session-expired-with-ajax/p1). I'm also using a slightly newer version of Kohana (3.3).
I've also tried setting the headers as soon as they reach the controller:
$this->response->headers('Access-Control-Allow-Origin', 'http://one.example.com');
$this->response->headers('Access-Control-Allow-Credentials', 'true');
$this->response->headers('Access-Control-Allow-Methods', 'POST, GET, OPTIONS');
However the Chrome inspector still shows the Access-Control-Allow-Origin as *.
The Problem
The problem I was having was due to a setting in my Apache config file which looked like this:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
In order to solve my particular problem I simple removed / commented out the above code as it was overriding the headers I sent from PHP.
My implemented solution was then quite simple. In the following example we'll assume that I am making a call from one.example.com (the main website) to two.example.com (a sub-site).
Kohana / PHP
In my PHP I set the following headers, I've chosen to do this in my parent Controller. You could create your own Cors class or helper if you prefer. Basically you don't want to have this code duplicated hundreds of times throughout your project.
$this->response->headers('Access-Control-Allow-Origin', 'http://one.example.com');
$this->response->headers('Access-Control-Allow-Credentials', 'true');
$this->response->headers('Access-Control-Allow-Methods', 'POST, GET, OPTIONS');
JavaScript / jQuery
In my $.ajax() requests I then have to make sure to set the xhrFields.withCredentials property to true.
$.ajax({
url: 'two.example.com',
xhrFields: {
withCredentials: true
}
});
Or I could set it globally for all ajax requests like so:
$(document).ajaxSend(function (event, xhr, settings) {
settings.xhrFields = {
withCredentials: true
};
});
For more information check the $.ajax documentation: http://api.jquery.com/jQuery.ajax/
Further Reading
For further information checkout the following resources:
https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
http://enable-cors.org/
So I've got a bookmarklet which executes javascript on other websites, which I want to trigger an 403 Authentication Required header, once the Cache button on it, is clicked. That way, a prompt will come up asking them to login.
The problem is that I'm not meant to provide an authentication header with the ajax request I am making, whilst having Access-Control-Allow-Origin: set to any domain with the * value. I'm supposed to explicitly define which domain I want to allow an 403 Authentication header to appear on, but I can't.
Here's my code.
.htaccess
header set Access-Control-Allow-Origin: *
#header set Access-Control-Allow-Methods: GET, POST, PUT, DELETE
header set Access-Control-Allow-Headers: Authorization
JQuery
$.ajax({
headers : {
"Authorization" : "Basic TVNF3TQtU1BGMjAx6C12bVxzbW4ydHBvaW50OlF3Z5J0eSEyM6Q1"
},
type: "GET",
url: 'http://desbest.uk.to/clickrobot/favicon.png', //image for testing
crossDomain:true,
xhrFields: {
withCredentials: true
},
//contentType: "application/json; charset=utf-8",
//dataType: "json",
success: function(data) {
alert('ok!');
//formatData(format_type,data);
},
error: function(jqXHR, textStatus, errorThrown) {
alert(textStatus + ' / ' + errorThrown);
}
});
The error I get
Cannot use wildcard in Access-Control-Allow-Origin when credentials
flag is true.
I've seen the Diigo bookmarklet do it, so it is possible, but how? Is it possible at all?
Let us take a look at the documentation. There are two things that should be noted:
...the browser will reject any response that does not have the
Access-Control-Allow-Credentials: true header...
and
Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding.
The headers that you should return are:
Access-Control-Allow-Origin: [some_origin]
Access-Control-Allow-Credentials: true
You can return the first header by obtaining the Referer using your server script, retrieve the origin from the Referer and then returning the header with your script. In PHP we can do that as follows:
$urllist = parse_url($_SERVER['HTTP_REFERER']);
$origin = $urllist['scheme'] . '://' . $urllist['host'];
header("Access-Control-Allow-Origin: " . $origin);
Update:
You should read Access-Control-Allow-Origin Multiple Origin Domains, in particular this answer. You might not need a PHP file if you can access your httpd.conf
Anyways, your url should not be the image, but the url to your PHP script.
url: 'http://desbest.uk.to/clickrobot/somescript.php'
In your php script you retrieve the origin of the request (which will be the page on which the bookmarklet appeared. And then you can output the header with the origin. Regardless, of where the bookmarklet appears, it should always about the correct header.
I'm not entirely sure, if the authorization dialog will popup using Ajax, even though you specified the correct headers. So, that is why we will have a look at Diigo below.
Diigo uses a different approach, namely: Once 'Sign in' has been clicked, JSONP is uses to request a javascript file which is generated by a server-side script (PHP for example) on their servers. JSONP is an alternative to CORS. JavaScript files from a different can be included in the page's header, with no problems at all, unlike Ajax requests.
If the user is not logged in, the request javascript file sends a 401 header on which the Authentication dialog is shown (this is coded in a server-side script!). The user enters his/her details and based on the entered information return the contents of the javascript file. If the user was successfully logged on it could return something like callback({ signedin : 1}), but otherwise callback({ signedin : 0}).
Now the javascript function callback with certain parameters are called. If the user is signed in, we display the bookmarklet's content.
What to put in your htaccess:
Untested, but you would like to allow all origins and set the 'Access-Control-Allow-Origin' header to the value of the origin. I believe this should do the trick:
SetEnvIf Origin "^(.*)$" ORIGIN_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_DOMAIN}e" env=ORIGIN_DOMAIN
Using Javascript or jQuery, how can I check if an external link is available?
An $.ajax() call is not available as it violates SOP (same problem as here). I have read about JSONP, but I would like to know if there is a more straight solution, as I don't want to load any data from the external server; what I need is only to check if it is reachable.
EDIT (answer)
I solved it with the following code:
$.ajax({url: 'http://www.example.com',
type: 'GET',
dataType: 'jsonp',
complete: function(jqXHR, textStatus) {
console.log(jqXHR.status); // '200' = url reachable
},
timeout: 2000
});
The only problem now is that I get a Parse error, but in any case it can be checked if the external link is working.
You could use YQL to check if a URL is available via its JSONP interface.
YQL Console.
Do you have access to server side languages? You could use AJAX to call a local file which uses something like PHP to check the external address.
If you need help with the PHP part, have a look at http://www.catswhocode.com/blog/amazing-things-to-do-with-php-and-curl
Yes, in browsers that support flash you can use this plugin. It has the same api as native xhr. Further if there is no flash plugin in browsers you still can access the other domain. In some browsers if your target domain response has the following headers there will not be an error.
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, *
Replace * with appropriate domains.
All above techniques are applicable only if the second domain is under your control. If not then you have to use a proxy as Jleagle said.