Can't manage to make CORS request working

Question

I'm trying to get some data from a webservice on a different domain, and I'm experiencing some CORS issue.

I have something like this in my controller :

$http({method: 'GET', url : 'http://somewebserviceapi.com?idAppli=' + appId, headers: {'Authorization': 'Basic dXNlcm5hbWU6cGFzc3dvcmQ='}}).
        success(function(data, status, headers, config) {
            console.log(data);
        }).
        error(function() {
            console.log("An error occured");
        });

And I'm getting the following errors :

OPTIONS http://somewebserviceapi.com?idLangue=1&idAppli=2153 b @ angular.js:9866n @ angular.js:9667$get.f @ angular.js:9383(anonymous function) @ angular.js:13248$get.n.$eval @ angular.js:14466$get.n.$digest @ angular.js:14282$get.n.$apply @ angular.js:14571showApplication @ viewerController.js:825handleApplications @ svgManipulation.js:15SvgPanZoom.handleMouseUp @ svg-pan-zoom.js:1195SvgPanZoom.setupHandlers.eventListeners.mouseup @ svg-pan-zoom.js:829

and

XMLHttpRequest cannot load http://somewebserviceapi.com?idLangue=1&idAppli=2153 . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access. The response had HTTP status code 401.

Now the headers :

When it is called from my controller : (It seems no authentification is made)

(Response)

Connection: Keep-Alive
Content-Length: 0
Date: Mon, 29 Jun 2015 14:33:09 GMT
Keep-Alive: timeout=5, max=100
Server: Apache
WWW-Authenticate: Negotiate
                  Basic realm="AD-ITS.SOME-COMPANY.COM"

(Request)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Access-Control-Request-Headers: authorization
Access-Control-Request-Methods: GET
Connection: keep-alive
Host: somewebserviceapi.com
Origin: http://localhost:63342
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

When I go myself to the url :

(Response)

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Origin, Accept, Authorization
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Length: 394
Content-Type: application/json;charset=UTF-8
Date: Mon, 29 Jun 2015 15:21:08 GMT
Keep-Alive: timeout=5, max=99
Server: Apache

(Request)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Connection: keep-alive
Cookie: JSESSIONID=89C1EC542BCBC42421C6207767EF8FA1
Host:  http://somewebserviceapi.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

And on Chrome, additionally to the response and request header there is a general header visible : In this header, I have :

From my controller request : Request Method:OPTIONS

When i go the URL myself : Request Method:GET

Apparently, the OPTIONS method is the way CORS handle some things, but do I need to add OPTIONS Method somewhere ?

Server side, I do have the Access-Control-Allow-Origin: * line, so I don't know how to fix this.

Answer 1

This is classic CORS issue, when you make a call from JS and CORS logic is applied then first call that will be made is OPTIONS which should return

200 OK with empty response (not sure if it really has to be empty)

and headers:

Access-Control-Allow-Methods: GET, POST, DELETE, PUT Access-Control-Allow-Origin: *

when the OPTIONS is correctly configured then another call will be made provided that method can be found in Access-Control-Allow-Methods: GET, POST, DELETE, PUT

although OPTIONS have to be added to Access-Control-Allow-Methods

Answer 2

It seems this is related to the preflight request (the OPTIONS request). Please take a look at this SO question Why does the preflight OPTIONS request of an authenticated CORS request work in Chrome but not Firefox?:

How can I get the OPTIONS request to send and respond consistently?

Simply have the server (API in this example) respond to OPTIONS requests without requiring authentication.

Kinvey did a good job expanding on this while also linking to an issue of the Twitter API outlining the catch-22 problem of this exact scenario interestingly a couple weeks before any of the browser issues were filed.

And see if it works for you. (Also, since this seems to be also a browser-related issue, please check on different browser and see what happens)