Cannot load Deezer API resources from localhost with the Fetch API - javascript

I'm trying to access the Deezer API from localhost, but I'm keep getting the following error:
Fetch API cannot load http://api.deezer.com/search/track/autocomplete?limit=1&q=eminem.
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost' 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.
localhost's response's headers does have Access-Control-Allow-Origin header
(Access-Control-Allow-Origin:*).
I'm using fetch like:
fetch('http://api.deezer.com/search/track/autocomplete?limit=1&q=eminem').
What am I doing wrong?

You can make the request through a public CORS proxy; to do that try changing your code to:
fetch('https://cors-anywhere.herokuapp.com/http://api.deezer.com/search/track/autocomplete?limit=1&q=eminem')
That sends the request through https://cors-anywhere.herokuapp.com, which forwards the request to http://api.deezer.com/search/track/autocomplete?limit=1&q=eminem and then receives the response. The https://cors-anywhere.herokuapp.com backend adds the Access-Control-Allow-Origin header to the response and passes that back to your requesting frontend code.
The browser will then allow your frontend code to access the response, because that response with the Access-Control-Allow-Origin response header is what the browser sees.
You can also set up your own CORS proxy using https://github.com/Rob--W/cors-anywhere/
For details about what browsers do when you send cross-origin requests from frontend JS code using XHR or the Fetch API or AJAX methods from JavaScript libraries—and details about what response headers must be received in order for browsers to allow frontend code to access the responses—see https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS.

For now, it is impossible to make this request. You can proxy request to API from your own backend or use jsonp. Here is a library with fetch-like syntax https://github.com/camsong/fetch-jsonp. Usage example https://jsfiddle.net/4dmfo0dd/1/
fetchJsonp('https://api.deezer.com/search/track/autocomplete?limit=1&q=eminem&output=jsonp')
.then(function(response) {
return response.json();
})
.then(json => console.log(json))
.catch(function(error) { console.log(error); });

CORS or Cross Origin requests made to servers
http://api.deezer.com/search/track/autocomplete?limit=1&q=eminem
in this case, have a preflight check enabled by all modern browsers.
and usually fail, if the server does not respond with Access-control headers.
In case of a fetch too, since you are basically fiddling with Javascript ,
You Need the Server to respond with Access-control-Allow-Origin Headers, which are flexible.
You Can not do Much about it Unless, the API itself becomes flexible and more open.
You however can Use fetch with mode set to no-cors
IFFF you only wish to cache the result of the request you make, to serve as a response, and not consume it yourself
Read Opaque Responses
No-CORS Definition
no-cors — Prevents the method from being anything other than HEAD, GET or POST. If any ServiceWorkers intercept these requests, they may not add or override any headers except for these. In addition, JavaScript may not access any properties of the resulting Response. This ensures that ServiceWorkers do not affect the semantics of the Web and prevents security and privacy issues arising from leaking data across domains

Related

Load large json file from external website with D3

On my site "mywebsite.com" I have a D3 javascript code running on some data set located at "otherwebsite.com/data.json", so I naively tried
d3.json("otherwebsite.com/data.json", function(error, json) {
if (!error) {
console.log('done loading',json)
} else {
console.log(error)
}
})
but of course it does not work :)
Access to XMLHttpRequest at 'otherwebsite/data.json' from origin 'https://mywebsite.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Anyone has a better idea? I should emphasize that it is a large file (200MB).
Thanks
Taken from the MDN page on CORS:
For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.
The CORS header in question is Access-Control-Allow-Origin which needs to either be explicitly set to https://mywebsite.com or be set to something that includes that, such as *.
If you have access to the server for "otherwebsite.com" you can change the header being sent with the request.
Otherwise you'll probably have to download the data server side on "mywebsite.com" and then have the front end request it from your back end, rather than making a cross origin request, so you'll change the JS to look like:
d3.json("/data.json", function(error, json) {...

How to force authentication in preflight request?

I'm trying to call Github REST API from client-side javascript (in browser).
My code does the following (I'm trying to get a zip containing the branch mkdocs_page of a private repository) :
const endpoint = 'https://api.github.com';
const resource = '/repos/astariul/private-gh-pages/zipball/mkdocs_page';
const options = {
mode: 'cors',
headers: {
'Authorization': 'Basic ' + btoa(`${pat}`), // pat contains my Personal Access Token
}
}
return fetch(`${endpoint}${resource}`, options);
But it does not work :
The preflight request fails with 404.
The console error message :
Access to fetch at 'https://api.github.com/repos/astariul/private-gh-pages/zipball/mkdocs_page' from origin 'null' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
In the process of debugging this, I tried to reproduce the problem with curl. And when I specify an authenticated request, it works :
curl --user "<my_PAT_token>" -i https://api.github.com/repos/astariul/private-gh-pages/zipball/mkdocs_page -X OPTIONS
HTTP/1.1 204 No Content
But if the request is not authenticated, it does not work :
curl -i https://api.github.com/repos/astariul/private-gh-pages/zipball/mkdocs_page -X OPTIONS
HTTP/1.1 404 Not Found
Note : it works fine when I'm trying to get the master branch (authenticated or not). However it fails after, when being redirected :
Access to fetch at 'https://codeload.github.com/astariul/private-gh-pages/legacy.zip/refs/heads/main?token=XXX' (redirected from 'https://api.github.com/repos/astariul/private-gh-pages/zipball') from origin 'null' 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.
Is it a bug in the Github API ? Or I'm doing something wrong ?
There’s no way to force authentication in a preflight request. The preflight is controlled totally by the browser, and nothing about it is exposed in any way that you can manipulate from frontend JavaScript code. And the requirements for the CORS protocol explicitly prohibit browsers from including any credentials in preflight requests.
For a detailed explanation, see the answer at https://stackoverflow.com/a/45406085/.
Since the preflight involves the browser making an OPTIONS request, then in general, if a server requires authentication for OPTIONS request to a particular resource (which seems to be the case for the GitHub URL cited in the question) that’s not at all necessarily an unintended bug.
That’s because the only normal case in which a preflight is performed and an OPTIONS request is sent is for the case of frontend JavaScript code running in a browser. Requests made from server-side code or from code running in shell/command-line environment or from desktop apps or native mobile apps don’t involve sending an OPTIONS request.
So, lack of support for unauthenticated OPTIONS requests to a particular resource would only be a bug if the provider actually intended it to be used from frontend code running in a browser. In other words, it can instead indicate the provider intentionally doesn’t want it to be used from frontend JavaScript code (which seems to be the case for the URL cited in the question).

Can fetch API from node.js but not from client [duplicate]

I tried to fetch the URL of an old website, and an error happened:
Fetch API cannot load http://xyz.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://abc' 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.
I understood the message, and tried to do a request that returns an opaque response:
fetch("http://xyz", {'mode': 'no-cors'})
Ok, it now works... but I can't read it. =\
What's the purpose then, of an opaque response?
Consider the case in which a service worker acts as an agnostic cache. Your only goal is serve the same resources that you would get from the network, but faster. Of course you can't ensure all the resources will be part of your origin (consider libraries served from CDNs, for instance). As the service worker has the potential of altering network responses, you need to guarantee you are not interested in the contents of the response, nor on its headers, nor even on the result. You're only interested on the response as a black box to possibly cache it and serve it faster.
This is what { mode: 'no-cors' } was made for.
Opaque responses can't be accessed by JavaScript, but you can still cache them with the Cache API and respond with them in the fetch event handler in a service worker. So they're useful for making your app offline, also for resources that you can't control (e.g. resources on a CDN that doesn't set the CORS headers).
There's also solution for Node JS app. CORS Anywhere is a NodeJS proxy which adds CORS headers to the proxied request.
The url to proxy is literally taken from the path, validated and proxied. The protocol part of the proxied URI is optional, and defaults to "http". If port 443 is specified, the protocol defaults to "https".
This package does not put any restrictions on the http methods or headers, except for cookies. Requesting user credentials is disallowed. The app can be configured to require a header for proxying a request, for example to avoid a direct visit from the browser. https://robwu.nl/cors-anywhere.html
javascript is a bit tricky getting the answer, I fixed it by getting the api from the backend and then calling it to the frontend.
public function get_typechange () {
$ url = "https://........";
$ json = file_get_contents ($url);
$ data = json_decode ($ json, true);
$ resp = json_encode ($data);
$ error = json_last_error_msg ();
return $ resp;
}

Javascript Fetch Not passing Cookies in the Request Headers, even with 'same-origin' credentials

I am attempting to make a Fetch request with Javascript using:
credentials: 'same-origin'
method: 'GET'
But in the fetch request I am unable to pass a client (browser) cookie in the request headers. I know that the issue is not a cors issue as that was corrected on both the client and server.
In the Header it looks like all other values are correct except that there is no cookie in the fetch request.
Since you had to correct a CORS issue, you must be making a cross-origin request.
That means it isn't a same-origin request and you need to use include not same-origin.
Note that the cookies sent will be the ones associated with the origin you are making the request to, not from.

Cross Domain JSON - does it matter what server provides source? [duplicate]

This question already has answers here:
XMLHttpRequest cannot load XXX No 'Access-Control-Allow-Origin' header
(11 answers)
Closed 3 years ago.
I've found simple tutorial how to make cross domain json call here
And it works perfectly fine, so i decided to use this example, just change url from:
var url = "http://api.myjson.com/bins/23xvb";
to
var url = "http://dl.sniper.pl/test.json"
Unfortunately changing it returns such an error (in chrome):
XMLHttpRequest cannot load http://dl.sniper.pl/test.json. 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.
Googling that error didnt provide any answers to find a solution so here's the question:
Why i get such an error and how to solve it?
The http://dl.sniper.pl/ server must be configured to send the Access-Control-Allow-Origin response header in responses to requests for http://dl.sniper.pl/test.json.
But because that server isn’t sending the Access-Control-Allow-Origin response header, your browser is refusing to allow your frontend JavaScript code to access that response.
So you either nust configure the http://dl.sniper.pl/ server to send Access-Control-Allow-Origin or else you can make the request through a CORS proxy.
There’s an open CORS proxy you can make you request through by changing your code to this:
var url = "https://cors-anywhere.herokuapp.com/http://dl.sniper.pl/test.json"
That sends the request through the open CORS proxy https://cors-anywhere.herokuapp.com which adds the Access-Control-Allow-Origin response header to it and then passes that back to your requesting frontend code as the response.
That response with the Access-Control-Allow-Origin response header is what the browser sees, so the browser allows your frontend JavaScript code to actually access the response.
You can also easily set up your own CORS proxy using https://github.com/Rob--W/cors-anywhere/
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS for an explanation of how browsers behave when you send cross-origin requests frontend JavaScript code using XHR or the Fetch API or AJAX methods from JavaScript libraries—and for details about what response headers must be received in order for browsers to allow frontend code to access the responses.
you should configure you server todo this in your htaccess
u need something like this
<RequireAll>
Require all granted
</RequireAll>

Categories