显然，我完全误解了它的语义。我想到了这样的事情：
客户端从下载JavaScript代码MyCode.jshttp://siteA-原产地。MyCode.js的响应标头包含Access Control Allow Origin：http://siteB，我认为这意味着允许MyCode.js对站点B进行跨源引用。客户端触发MyCode.js的一些功能，进而向http://siteB，这应该可以，尽管是跨源请求。
嗯，我错了。它根本不是这样工作的。所以，我已经阅读了跨源资源共享，并尝试阅读w3c推荐中的跨源资源分享。
有一点是肯定的——我仍然不明白我应该如何使用这个标题。
我完全控制站点A和站点B。如何使从站点A下载的JavaScript代码使用此标头访问站点B上的资源？
备注：我不想使用JSONP。
当前回答
根据我自己的经验，很难找到一个简单的解释，为什么CORS甚至是一个问题。
一旦你明白了为什么会出现，标题和讨论就会变得更加清晰。我会在几行字里尝试一下。
都是关于饼干的。Cookie按其域存储在客户端上。
一个例子：在你的电脑上，有一个你的bank.com的cookie。也许你的会话就在那里。
要点：当客户端向服务器发出请求时，它将发送存储在该请求的域下的cookie。
您已在浏览器上登录到yourbank.com。您请求查看您的所有帐户，并为yourbank.com发送cookie。yourbank.com收到一堆cookie，并发回其响应（您的帐户）。
如果另一个客户机向服务器发出跨源请求，则会像以前一样发送这些cookie。如罗。
你浏览到malicious.com。malicious向不同的银行发出一系列请求，包括yourbank.com。
由于cookie按预期进行了验证，服务器将授权响应。
这些饼干被收集起来并一起发送——现在，malious.com收到了您银行的回复。
诶呀
现在，一些问题和答案变得显而易见：
“我们为什么不阻止浏览器这样做？”是的。这是CORS。“我们怎么解决？”让服务器告诉请求CORS正常。
其他回答
访问控制允许源是CORS（跨源资源共享）标头。
当站点A尝试从站点B获取内容时，站点B可以发送一个访问控制允许源站响应标头，告诉浏览器此页面的内容可由特定源站访问。（源站是一个域，加上一个方案和端口号。）默认情况下，站点B的页面不可由任何其他源站访问；使用Access Control Allow Origin（访问控制允许来源）标头为特定请求来源的跨来源访问打开了一扇门。
对于站点B希望站点A访问的每个资源/页面，站点B应为其页面提供响应标题：
Access-Control-Allow-Origin: http://siteA.com
现代浏览器不会完全阻止跨域请求。如果站点A从站点B请求页面，浏览器将在网络级别实际获取请求的页面，并检查响应标头是否将站点A列为允许的请求者域。如果站点B未指示站点A被允许访问此页面，浏览器将触发XMLHttpRequest的错误事件，并拒绝向请求的JavaScript代码提供响应数据。
非简单请求
在网络层面发生的事情可能比上面解释的稍微复杂一些。如果请求是“非简单”请求，则浏览器首先发送一个无数据的“预检”OPTIONS请求，以验证服务器是否接受该请求。在以下情况之一（或两者）时，请求是非简单的：
使用GET或POST以外的HTTP动词（例如PUT、DELETE）使用非简单请求头；唯一简单的请求头是：接受接受语言内容语言内容类型（仅当其值为application/x-wwww-form-urlencoded、multipart/form-data或text/plain时才简单）
如果服务器使用与非简单谓词和/或非简单标头匹配的适当响应标头（非简单标头的访问控制允许标头，非简单谓词的访问控制方法）响应OPTIONS预检，则浏览器发送实际请求。
假设站点A想要发送一个对/somePage的PUT请求，其中一个非简单的Content-Type值为application/json，浏览器将首先发送一个预检请求：
OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
注意，访问控制请求方法和访问控制请求头由浏览器自动添加；您不需要添加它们。此OPTIONS预检获得成功的响应标头：
Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
在发送实际请求时（飞行前完成后），行为与处理简单请求的方式相同。换言之，预飞成功的非简单请求被视为简单请求（即，服务器仍然必须再次发送访问控制允许源以获得实际响应）。
浏览器发送实际请求：
PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json
{ "myRequestContent": "JSON is so great" }
服务器会发回一个“访问控制允许源”，就像对一个简单的请求一样：
Access-Control-Allow-Origin: http://siteA.com
有关非简单请求的更多信息，请参阅了解CORS上的XMLHttpRequest。
跨源资源共享-CORS（A.K.A.跨域AJAX请求）是大多数web开发人员可能遇到的问题，根据同源策略，浏览器在安全沙盒中限制客户端JavaScript，通常JS无法直接与来自不同域的远程服务器通信。过去，开发人员创建了许多复杂的方法来实现跨域资源请求，最常用的方法是：
使用Flash/SSilverlight或服务器端作为“代理”进行通信使用遥控器。带填充的JSON（JSONP）。在iframe中嵌入远程服务器，并通过fragment或window.name进行通信，请参阅此处。
这些棘手的方法或多或少都有一些问题，例如，如果开发人员简单地“评估”JSONP，JSONP可能会导致安全漏洞，而上面的第3条，虽然它有效，但两个域之间应该建立严格的契约，它既不灵活也不优雅IMHO：）
W3C引入了跨源资源共享（CORS）作为标准解决方案，以提供一种安全、灵活和推荐的标准方式来解决这个问题。
机制
从高层次上讲，我们可以简单地将CORS视为来自域a的客户端AJAX调用与域B上托管的页面之间的契约，典型的跨源请求/响应将是：
DomainA AJAX请求标头
Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com
DomainB响应标头
Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive
上面我标记的蓝色部分是核心事实，“Origin”请求头“表示跨源请求或飞行前请求的来源”，“Access Control Allow Origin”响应头表示此页面允许来自DomainA的远程请求（如果值为*，则表示允许来自任何域的远程请求）。
如上所述，W3建议浏览器在提交实际的跨源HTTP请求之前实现一个“预飞行请求”，简而言之，这是一个HTTP OPTIONS请求：
OPTIONS DomainB.com/foo.aspx HTTP/1.1
如果foo.aspx支持OPTIONS HTTP动词，它可能会返回如下响应：
HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json
只有当响应包含“Access Control Allow Origin”且其值为“*”或包含提交CORS请求的域时，通过满足此强制条件，浏览器才会提交实际的跨域请求，并将结果缓存在“Preflight result cache”中。
三年前，我在博客中写到了CORS：AJAX跨源HTTP请求
只需将以下代码粘贴到web.config文件中。
注意，您必须在<system.webServer>标记下粘贴以下代码
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
</customHeaders>
</httpProtocol>
注：仅用于测试的临时解决方案
对于那些无法控制“选项405方法不允许”的后端的人，这里有一个解决方案，用于“颜色”浏览器。
在命令行中执行：
“C:\Program Files（x86）\Google\Chrome\Application\Chrome.exe”--禁用web安全--用户数据dir=“path_to_file”
例子：
“C:\Program Files（x86）\Google\Chrome\Application\Chrome.exe”--禁用web安全--用户数据dir=“C:\Users\vital\AppData\Local\Google\Cherme\user data\Profile 2”
在Python中，我一直在成功地使用Flask CORS库。它使处理CORS变得非常容易和轻松。我从下面的库文档中添加了一些代码。
安装：
pip install -U flask-cors
允许所有路由上所有域的CORS的简单示例：
from flask import Flask
from flask_cors import CORS
app = Flask(__name__)
CORS(app)
@app.route("/")
def helloWorld():
return "Hello, cross-origin-world!"
有关更多具体示例，请参阅文档。我使用了上面的简单示例来解决我正在构建的Ionic应用程序中的CORS问题，该应用程序必须访问单独的烧瓶服务器。
