XMLHttpRequest无法加载https：// www。[website] .com / [英] XMLHttpRequest cannot load https://www.[website].com/
问题描述
我有一个Grunt进程启动一个express.js服务器的实例。这是非常正常的工作，直到刚刚开始提供一个空白页，在Chrome（最新版本）开发人员控制台的错误日志中出现以下内容：
XMLHttpRequest无法加载 https：// www。[website] .com /
否在所请求的
资源上存在Access-Control-Allow-Origin头。原因 http：// localhost：4300 因此不允许访问。
关于同源政策
这是相同原产地政策。这是一个由浏览器实现的安全功能。
您的特定情况显示如何实现XMLHttpRequest（如果您使用fetch，您将获得相同的结果） ，但它也适用于其他事物（例如加载到< canvas> 上的图像或加载到< iframe> ），只是略有不同的实现。
表示SOP需要的标准场景是：
- Alice是具有网络浏览器的人
- Bob在您的网站上运行一个网站（
https：// www。[website] .com /示例） - Mallary在您的示例中运行一个网站（
http：// localhost：4300）
Alice登录到Bob的网站，并在那里有一些机密数据。也许它是一个公司内部网（只能访问局域网上的浏览器）或她的网上银行（只能通过输入用户名和密码后获得的Cookie访问）。
Alice访问Mallary的网站，它有一些JavaScript，使得Alice的浏览器向Bob的网站发送HTTP请求（使用她的Cookie等从她的IP地址）。
同源策略防止JavaScript读取Bob的网站返回的数据（Bob和Alice不希望Mallary访问）。 （请注意，例如，您可以使用跨元素的< img> 元素显示图像，因为图像的内容不会暴露给JavaScript ...除非你抛出画布
为什么会出现这种情况如果您认为不适用，则适用同源策略
这就是SOP存在的原因。对于任何给定的URL，可能不需要SOP。
- Alice，Bob和Mallary是同一个人。
- Bob可能提供完整的公开资讯
...但浏览器无法知道如果上述任一个是真的，则信任不是自动的，并且应用SOP。
只适用于网页中的JavaScript
像Postman这样的工具，可以安装为浏览器扩展，绕过SOP，因为它是安装的软件。这意味着浏览器隐式地信任Postman。
其他独立软件也没有适用于同源策略。
这是因为它是一个故意安装的程序（因此带有一个信任的假设）。这不是代码Alice正在通过访问Mallary的网站运行。
CORS
-Control-Allow-Origin 错误消息中引用的标头是 CORS 标准，允许Bob通过Alice的浏览器明确授权Mallary的网站访问数据。
很明显，这是Bob只有在以下情况下才会做的：
- 数据不是私人或
- Mallary受信任
您在这种情况下也是Bob，那么您如何添加CORS权限标头的具体细节将取决于您选择的HTTP服务器软件和您用于服务器端编程（如果有）的语言的某种组合。
无法添加此标题，因为她必须获得Bob的网站的许可，并且她会愚蠢地（为了使SOP无用）能够授予自己许可。
CORS的替代品
JSONP
Bob也可以使用hack（例如 JSONP 这是人们在CORS出现之前如何跨越Ajax的。
它的工作原理是以JavaScript程序的形式呈现数据， Mallary的页面。
它要求Mallary信任Bob不提供恶意代码。
请注意常见的主题：提供数据的站点必须告诉浏览器，第三方网站可以访问发送到浏览器的数据。
将这两个资源移动到一个原始
如果JS运行的HTML文档，请求是在同一起源（共享相同的方案，主机名和端口），那么他们相同的起源策略授予权限默认情况下。
可以使用服务器端代码它会添加CORS头文件，将响应转换为JSONP，或存在于与HTML文档相同的原点上。
服务器端代码可以由第三方托管（如YQL）。
Bob不需要授予任何权限。
这很好，因为它只是在Mallary和Bob之间。 Bob没有办法认为Mallary是Alice，并且向Mallary提供应该在Alice和Bob之间保密的数据。
因此，Mallary只能使用技术来读取公共数据。
其他安全风险
请注意，SOP / CORS不减轻 XSS ， CSRF 或 SQL注入需要独立处理的攻击。
摘要
- 服务器 如果您控制了您的客户端代码，
- 如果您与控制它的人友好：让他们为其添加CORS权限。
- 如果它是一个公共服务：阅读他们的API文档，看看他们对使用客户端JavaScript访问它们说什么。他们可能会告诉您使用特定的网址或使用JSONP（或者根本不支持）。
- 如果以上都不适用：
I have a Grunt process which initiates an instance of express.js server. This was working absolutely fine up until just now when it started serving a blank page with the following appearing in the error log in the developer's console in Chrome (latest version):
XMLHttpRequest cannot load https://www.[website].com/ No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4300' is therefore not allowed access.
What is stopping me from accessing the page?
About the Same Origin Policy
This is the Same Origin Policy. It is a security feature implemented by browsers.
Your particular case is showing how it is implemented for XMLHttpRequest (and you'll get identical results if you were to use fetch), but it also applies to other things (such as images loaded onto a <canvas> or documents loaded into an <iframe>), just with slightly different implementations.
The standard scenario that demonstrates the need for the SOP is:
- Alice is a person with a web browser
- Bob runs a website (
https://www.[website].com/in your example) - Mallary runs a website (
http://localhost:4300in your example)
Alice is logged into Bob's site and has some confidential data there. Perhaps it is a company intranet (accessible only to browsers on the LAN), or her online banking (accessible only with a cookie you get after entering a username and password).
Alice visits Mallary's website which has some JavaScript that causes Alice's browser to make an HTTP request to Bob's website (from her IP address with her cookies, etc).
The browser's Same Origin Policy prevents that JavaScript from reading the data returned by Bob's website (which Bob and Alice don't want Mallary to access). (Note that you can, for example, display an image using an <img> element across origins because the content of the image is not exposed to JavaScript … unless you throw canvas into the mix in which case you will generate a same origin violation error).
Why the Same Origin Policy applies when you don't think it should
That's why the SOP exists. For any given URL it is possible that the SOP is not needed.
- Alice, Bob and Mallary are be the same person.
- Bob might be providing entirely public information
… but the browser has no way of knowing if either of the above are true, so trust is not automatic and the SOP is applied.
Why the Same Origin Policy only applies to JavaScript in a web page
A tool like Postman, which is an application that can be installed as a browser extension, bypasses the SOP because it is installed software. This means that the browser trusts Postman implicitly.
Other standalone software also doesn't have the Same Origin Policy apply to it.
This is because it is a program that has been deliberately installed (and thus comes with an assumption of trust). It isn't code Alice is running just by visiting Mallary's website.
CORS
The Access-Control-Allow-Origin header referred to in the error message is part of the CORS standard which allows Bob to explicitly grant permission to Mallary's site to access the data via Alice's browser.
Obviously this is something Bob would only do only if either:
- The data was not private or
- Mallary was trusted
If you are also Bob in this scenario, then the specifics of how you add CORS permission headers will depend on some combination of your choice of HTTP server software and what language you are using for server side programming (if any).
Mallary can't add this header because she has to get permission from Bob's site and it would be silly (to the point of rendering the SOP useless) for her to be able to grant herself permission.
Alternatives to CORS
JSONP
Bob could also provide the data using a hack like JSONP which is how people did cross-origin Ajax before CORS came along.
It works by presenting the data in the form of a JavaScript program which injects the data into Mallary's page.
It requires that Mallary trust Bob not to provide malicious code.
Note the common theme: The site providing the data has to tell the browser that it is OK for a third party site to access the data it is sending to the browser.
Move the two resources to a single Origin
If the HTML document the JS runs in and the URL being requested are on the same origin (sharing the same scheme, hostname, and port) then they Same Origin Policy grants permission by default. CORS is not needed.
A Proxy
Mallary could use server side code to fetch the data (which she could then pass from her server to Alice's browser through HTTP as usual).
It will either add CORS headers, convert the response to JSONP, or exists on the same origin as the HTML document.
That server side code could be hosted by a third party (such as YQL).
Bob wouldn't need to grant any permissions for that to happen.
This would be fine since that is just between Mallary and Bob. There is no way for Bob to think that Mallary is Alice and to provide Mallary with data that should be kept confidential between Alice and Bob.
Consequently, Mallary can only use this technique to read public data.
Other security risks
Note that SOP / CORS do not mitigate XSS, CSRF, or SQL Injection attacks which need to be handled independently.
Summary
- There is nothing you can do in your client-side code that will enable CORS access to someone else's server.
- If you control the server the request is being made to: Add CORS permissions to it.
- If you are friendly with the person who controls it: Get them to add CORS permissions to it.
- If it is a public service: Read their API documentation to see what they say about accessing it with client side JavaScript. They might tell you to use specific URLs or to use JSONP (or they might not support it at all).
- If none of the above apply: Get the browser to talk to your server instead, and then have your server fetch the data from the other server and pass it on.
这篇关于XMLHttpRequest无法加载https：// www。[website] .com /的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
