无法解决的CORS问题！ 如何在MacOS上禁用Chrome的相同来源策略？

Question

For a while, I keep facing a problem about CORS. I'm running an ExtJS app with localhost and during REST process on Delete process, it keeps giving this error:

Response for preflight has invalid HTTP status code 403.

I've already reached these topics;

• Several CORS issues & ideas to fix @ https://stackoverflow.com/a/35588856/7163711
• Disable Chrome web security @ https://stackoverflow.com/a/3177718/7163711

---

I did several things but none of them worked for me!

Using extension for CORS: Allow-Control-Allow-Origin: * and here is a screenshot of extension's settings:

I've Chrome Canary on MacOS and running it with web-security-disabled . The browser is opening with FLAG and notice that this is web-security-disabled mod but somehow it does not behave as expected. Here is the terminal command I've used to run it:

open -a /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --args --disable-web-security --/ChromeDisabled

But it's not working as well! So what am I doing wrong? How can I solve this problem?

Answer 1

I guess you want to solve the puzzle why it gives Error 403. The problem lies on the server-side, not in the browser nor in ExtJS.

Error 403 means "Unauthorized". So, why are you unauthorized? And what is a "preflight"?

A preflight request is a special request sent to the backend by the browser using the OPTIONS HTTP method. It is sent before the actual request, and it is sent without headers, cookies or other authentication data. It should not return the data, only a few headers indicating from which domains CORS requests are allowed to access the URL, and which methods and headers they may send. If the browser finds that the response information allows it to send the actual request, it will send the actual request and process the returned data.

So, to support CORS, OPTIONS requests against the backend have to always go through unauthenticated, since no authentication information can be sent. Your backend, however, does not allow OPTIONS requests to go through unauthenticated.

You may want to check which authentication code you use and try to get OPTIONS requests around authentication (of course, they shouldn't return any data then). I have no knowledge about your backend technology, you may want to ask how to solve this in another question with the correct tags; in C# it would be like this (I guess you have similar functions at your disposal somehow):

[HttpOptions]
[AllowAnonymous]
public HttpResponseMessage GenerateDemoKey() {
    var response = Request.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Access-Control-Allow-Origin", "*");
    response.Headers.Add("Access-Control-Allow-Methods", "GET, POST, PATCH, PUT, DELETE, OPTIONS");
    response.Headers.Add("Access-Control-Allow-Headers", "Origin, Content-Type, X-Auth-Token, X-Requested-With, Authorization");
    return response;
}

So, if it's an OPTIONS request (line 1), to the URL .../GenerateDemoKey (line 3) it may go through unauthorized (line 2), and the response with Status 200: OK (line 4) has headers added that tell the browser that sites from any domain are allowed to access the real URL (line 5), as long as they use one of the six named methods (line 6) and send only the five named headers (line 7).

In PHP, on the other hand, you would add an if block to the start of your script, before you process the authentication :

<?php
if($_SERVER['REQUEST_METHOD']=="OPTIONS") {
    header("Access-Control-Allow-Origin: *")
    header("Access-Control-Allow-Methods: GET, POST*")
    header("Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token, X-Requested-With, Authorization")
    exit(0);
}

If you use htaccess to authenticate, you may have to add a rule to the htaccess file to allow OPTIONS requests to pass through. With the combination of htaccess and PHP, there's a huge security risk there - make double sure to only whitelist those URLs that you have checked won't return private information when called with the OPTIONS method.