Javascript – Access-Control-Allow-Origin denied spotify api

javascriptjqueryrestspotify

I'm trying to access to the Spotify API token like so:

$.ajax({
  url: "https://accounts.spotify.com/api/token",
  type: 'POST',
  contentType: "application/json; charset=\"utf-8\"",
  crossDomain: true,
  data: {
    grant_type: "authorization_code",
    code: code,
    redirect_uri: "http://www.bancadigital.com.br/spotifyteste/callback.html"
  },
  processData: false,
  dataType: "json",
  headers: {
    Authorization: "Basic " + utf8_to_b64(key)
  },
  success: function( response ) {
    alert(response.access_token);
  },
});

but the service returns the following error:

XMLHttpRequest cannot load https://accounts.spotify.com/api/token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.bancadigital.com.br' is therefore not allowed access.

Does anyone know how I can access the service?

Best Solution

The request to https://accounts.spotify.com/api/token needs to be made server side and not as an AJAX request.

This way your key, which contains the credentials for your application, won't be exposed. Also, the Spotify server will be able to redirect the request to the redirect_uri together with the access token.

An alternative is to use the implicit grant flow where you can run everything client side, but you will not get a refresh token.

I would recommend you to review the Spotify Web API Authorization Guide, check the GitHub repo with auth examples and take a look at the libraries and wrappers that make it easier to implement the OAuth flow.

Related Solutions

Javascript – “Origin null is not allowed by Access-Control-Allow-Origin” error for request made by application running from a file:// URL

For the record, as far as I can tell, you had two problems:

You weren't passing a "jsonp" type specifier to your $.get, so it was using an ordinary XMLHttpRequest. However, your browser supported CORS (Cross-Origin Resource Sharing) to allow cross-domain XMLHttpRequest if the server OKed it. That's where the Access-Control-Allow-Origin header came in.
I believe you mentioned you were running it from a file:// URL. There are two ways for CORS headers to signal that a cross-domain XHR is OK. One is to send Access-Control-Allow-Origin: * (which, if you were reaching Flickr via $.get, they must have been doing) while the other was to echo back the contents of the Origin header. However, file:// URLs produce a null Origin which can't be authorized via echo-back.

The first was solved in a roundabout way by Darin's suggestion to use $.getJSON. It does a little magic to change the request type from its default of "json" to "jsonp" if it sees the substring callback=? in the URL.

That solved the second by no longer trying to perform a CORS request from a file:// URL.

To clarify for other people, here are the simple troubleshooting instructions:

If you're trying to use JSONP, make sure one of the following is the case:
- You're using $.get and set dataType to jsonp.
- You're using $.getJSON and included callback=? in the URL.
If you're trying to do a cross-domain XMLHttpRequest via CORS...
1. Make sure you're testing via http://. Scripts running via file:// have limited support for CORS.
2. Make sure the browser actually supports CORS. (Opera and Internet Explorer are late to the party)

Javascript – How does Access-Control-Allow-Origin header work

Access-Control-Allow-Origin is a CORS (Cross-Origin Resource Sharing) header.

When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins. (An origin is a domain, plus a scheme and port number.) By default, Site B's pages are not accessible to any other origin; using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins.

For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:

Access-Control-Allow-Origin: http://siteA.com

Modern browsers will not block cross-domain requests outright. If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain. If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest's error event and deny the response data to the requesting JavaScript code.

Non-simple requests

What happens on the network level can be slightly more complex than explained above. If the request is a "non-simple" request, the browser first sends a data-less "preflight" OPTIONS request, to verify that the server will accept the request. A request is non-simple when either (or both):

using an HTTP verb other than GET or POST (e.g. PUT, DELETE)
using non-simple request headers; the only simple requests headers are:
- Accept
- Accept-Language
- Content-Language
- Content-Type (this is only simple when its value is application/x-www-form-urlencoded, multipart/form-data, or text/plain)

If the server responds to the OPTIONS preflight with appropriate response headers (Access-Control-Allow-Headers for non-simple headers, Access-Control-Allow-Methods for non-simple verbs) that match the non-simple verb and/or non-simple headers, then the browser sends the actual request.

Supposing that Site A wants to send a PUT request for /somePage, with a non-simple Content-Type value of application/json, the browser would first send a preflight request:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically; you do not need to add them. This OPTIONS preflight gets the successful response headers:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled. In other words, a non-simple request whose preflight is successful is treated the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin again for the actual response).

The browsers sends the actual request:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

And the server sends back an Access-Control-Allow-Origin, just as it would for a simple request:

Access-Control-Allow-Origin: http://siteA.com

See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.