获取API；为什么使用“ no-cors”？模式是否响应为不透明？ [英] Fetch API; why use the "no-cors" mode if the response is Opaque?

问题描述

我阅读了这个问题和此问题。前者只解释无条件与相同来源；后者建议因为不透明响应（Javascript无法读取/做任何有用的事情），因此'no-cors'无效。

I read this question and this question . The former only explains 'no-cors' vs 'same-origin'; the latter recommends that 'no-cors' is not useful because of the Opaque Response (which Javascript cannot read/do anything useful with):

您基本上永远不会使用以下模式：实践中 no-cors —
，但在某些非常有限的情况下除外。那是因为设置模式：
'no-cors'实际上对浏览器说的是，在任何情况下，阻止我的前端
JavaScript代码查看响应主体
和标头的内容。在大多数情况下，显然
确实不是您想要的。

You basically never ever want to use mode: 'no-cors' in practice — except in some very limited cases. That’s because what setting mode: 'no-cors' actually says to the browser is, "Block my frontend JavaScript code from looking into the contents of the response body and headers under all circumstances." In most cases that’s obviously really not what you want.

有人可以建议这些例子是什么有限的情况（我们希望使用无心）（即使响应是不透明的）。

我唯一想到的情况是一种单向通信；如果客户端足以将GET或POST发送到服务器，则简单地使服务器可以跟踪请求的发生； （例如，增加请求计数器）； ...

The only case I can think of is a sort of one-way communication; if it is sufficient for the client to send a GET or POST to the server, simply so the server can track that the request happened; (for example, to increment a request counter); ...

...那么，将响应变成OpaqueResponse就足够了；即客户只需要知道请求是否成功（状态200），就不会期望任何有效负载响应。

...then it is sufficient for the response to be an OpaqueResponse; i.e. the client only need to know if the request was successful (status 200), doesn't expect any payload response.

我的想法是否有效？有人可以推荐其他可能性/用例/无心用法的示例吗？

Is my idea a valid example? Can someone recommend other possibilities / use-cases / examples of 'no-cors' usage?

推荐答案

请记住，CORS设置不起作用阻止请求到达服务器-这就是身份验证和CSRF的目的。相反，它防止页面读取响应。请求仍然是：

Remember that CORS settings doesn't prevent a request from reaching the server - that's what authentication and CSRF is for. Instead, it prevents responses from being read by the page. The request is still:

1. 从页面发送，


2. 浏览器添加了 Origin 标头


3. 服务器仍在处理它（通常-CORS与之无关，尽管可能还有其他安全措施），


4. ，当返回时，浏览器检查响应标头中的 Access-Control-Allow-Origin 。如果它与浏览器认为的 Origin 相匹配，则浏览器将使页面看到请求的结果。

1. sent from the page,
2. the browser adds the Origin header,
3. it's still processed by the server (generally - CORS has nothing to do with this, although there maybe other security in place),
4. and when returned the browser checks the response header for Access-Control-Allow-Origin. If it matches what the browser thinks is the Origin then the browser lets the page see the result of the request.

这是关键-同源策略和CORS设置不允许协作浏览器中的页面看到响应。

请注意，上面还有第0步。这是一个选项，发送飞行前检查以检查是否通过了请求，该页面是否可以看到结果？如果不是，则他们认为发送请求毫无意义-但这只是一个假设。

Note also there is a step 0. above, which is an OPTIONS "pre-flight check" is sent to check that if the request was to go through would the page be allowed to see the result? If not, then they assume there is little point in sending the request - but that is an assumption.

模式：无心做两件事：

1. 它说我不需要查看结果


2. ，因此它不会发送飞行前检查

在我的头顶上，这就是我可以用来（某些邪恶）的方法

• 每当我不需要查看响应时，例如日志记录，跟踪或黑客入侵；当前端代码本质上是一个 try {const notNeeded = fetch（...）} catch {console.log（运气不好，什么也不做）}


• 每一次我都想通过不发送飞行前检查将数据尽快发送到服务器。以后，我总是可以在需要时发送带有CORS的GET来读取数据。


• 缓存，此答案中有详细说明



Off the top of my head, here's what I think I could use it for (some of them nefarious)

• Any time when I don't need to see the response, such logging, tracking, or hacking; when the frontend code is essentially a try { const notNeeded = fetch(...) } catch { console.log('Tough luck, do nothing') }
• Any time I want to send the data to the server as fast as possible by not sending a preflight check. I can always send a GET with CORS later on to read the data when I really need it.
• Caching, detailed in this answer

CORS可以完成上述操作。它不会执行以下操作：

CORS does the above. It doesn't do the following:



• 防止服务器处理请求-这就是身份验证和CSRF防护的目的。


• 停止欺骗Origin标头-仅适用于合作的浏览器。作为攻击者，您通常无法访问用户使用的浏览器。由于标头可以被欺骗，因此服务器不应使用其中的数据来确保安全。 （这就是为什么通过诸如CURL / Postman / Insomnia之类的工具测试浏览器API时，您需要检查CORS标头是否通过，因为它们接受所有响应并且从未应用CORS策略。）



这篇关于获取API；为什么使用“ no-cors”？模式是否响应为不透明？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！