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

问题描述

我阅读了这个问题 和 这个问题 .前者只解释了no-cors"与same-origin"；后者建议 'no-cors' 没有用，因为不透明响应(Javascript 无法读取/做任何有用的事情):

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):

实际上，您基本上永远不想使用 mode: '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.

有人可以建议我们希望使用no-cors"的这些有限情况"的示例(即使响应是不透明的?)

我能想到的唯一情况是一种单向通信；如果客户端向服务器发送 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.

我的想法是一个有效的例子吗?有人可以推荐其他可能性/用例/'no-cors'用法示例吗?

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.，这是一个 OPTIONS 飞行前检查"，用于检查请求是否通过，是否允许页面查看结果?如果不是，那么他们认为发送请求没有什么意义 - 但这是一个假设.

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.

mode: no-cors 做了两件事:

1. 它说我不需要看到结果
2. 因此它不会发送飞行前检查

在我的脑海中，这就是我认为我可以用它来做的事情(其中一些是邪恶的)

• 任何时候我不需要查看响应，例如日志记录、跟踪或黑客攻击；当前端代码本质上是一个 try { const notNeeded = fetch(...) } catch { console.log('Tough lucky, do nothing') }
• 任何时候我想通过不发送预检检查尽快将数据发送到服务器.以后我可以随时发送带有 CORS 的 GET，以便在我真正需要时读取数据.
• 缓存，详见本答案

CORS 执行上述操作.它不执行以下操作:

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

• 阻止服务器处理请求 - 这就是身份验证和 CSRF 预防的用途.
• 停止欺骗 Origin 标头 - 这仅适用于合作浏览器.作为攻击者，您通常无权访问用户正在使用的浏览器.因为标头可以被欺骗，服务器不应该使用其中的数据来保证安全.(这就是为什么在通过 CURL/Postman/Insomnia 之类的工具测试浏览器 API 时，您需要检查 CORS 标头是否通过，因为它们接受所有响应并且永远不会应用 CORS 策略.)

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