有没有纯 IP 的呢？

同

@UnluckyNinja > 在跨域的语境下，你要搞清楚哪方是攻击方，哪方是受保护方（响应端、用户是被保护方，请求端是潜在的攻击方）。 这句话很经典，受教了

@unco020511 是的，你这个第二点说的很对，用户凭证这个东西不是标准，每个网站实现都不一样，所以我才对这个 MDN 里面关于用户凭证对 Access-Control- 各种头部的限制和要求不太理解。 有点疑惑。

@unco020511 其实第一个情况，要考虑到类似 jscdn 这种网站到期了被抢注了，这种域名被篡改了之类的，我做为黑客不一定要中间人攻击请求报文或响应报文，我可能攻击了类似 CDN 这种。 比如说我攻破大家都在用的 <script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/axios.min.js"></script> 假设这是我的恶意脚本，在这脚本里面去请求我的网站呢。

以 MDN 为例，站点 https://foo.example 的网页应用想要访问 https://bar.other 的资源。

如果 https://bar.other 的资源持有者想限制他的资源只能通过 https://foo.example 来访问（也就是说，非 https://foo.example 域无法通过跨源访问访问到该资源）

那我做为 bar.other 来说，我可能有两类资源，一类是静态的什么 js 啥的，第二类是 api 接口业务数据啥的

我想保护我自己。 所谓我可能要在一些有认证态(抱歉这是我造的词，不同网站可能不一样)的 http web api 加上响应头限制。 "Access-Control-Allow-Origin: https://foo.example:" 表示只能是 Origin 为 foo 的请求才能接收。 关键是这个响应已经发出去了啊， 我的保护意义何在呢？


所以如果我设置失误了，对于带 cookie 或者说认证状态的请求，我在响应头 "Access-Control-Allow-Origin: *"设置为这样，浏览器反而自动给我加了个保护，响应虽然发出去了， 在浏览器不解析这个响应报文数据。 ？ 所以这是君子协定，靠浏览器的机制保护来约束？

可能这些才是我的疑惑，这些头部约束的目的和要解决的问题其实我是明白的，我其实想问它的控制机制和限制，


MDN 这一系列不能，只是为了安全考虑，如果我设置了会怎么样他没说，并且还是那句话，不同的网站，带身份凭证的请求各有不同，做为这种跨域约束协定，或者说我用某个头部做为认证，然后不小心设置了 Access-Control-Allow-Origin: * ， 客户端怎么判断请求是否带身份凭证呢？怎么判断这个*应该不被接收呢？


```

在响应附带身份凭证的请求时：

服务器不能将 Access-Control-Allow-Origin 的值设为通配符（*），而应将其设置为特定的域，如：Access-Control-Allow-Origin: https://example.com 。
服务器不能将 Access-Control-Allow-Headers 的值设为通配符（*），而应将其设置为特定标头名称的列表，如：Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
服务器不能将 Access-Control-Allow-Methods 的值设为通配符（*），而应将其设置为特定请求方法名称的列表，如：Access-Control-Allow-Methods: POST, GET
服务器不能将 Access-Control-Expose-Headers 的值设为通配符（*），而应将其设置为特定标头名称的列表，如：Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
对于附带身份凭证的请求（通常是 Cookie ），

这是因为请求的标头中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 https://example.com ，则请求将成功执行。

另外，响应标头中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。
```


@GeruzoniAnsasu
@GeruzoniAnsasu

@seekafter 可以出一篇文章详解一下，等你大作。大家都在说跨域是浏览器行为， 这个我的理解是这样的，浏览器是个公共应用，用户打开浏览器可以访问各种各样的域名各种各样的网站。 网站会在客户端存各种各样的数据（比如用户身份登录态（抱歉这是我自己造的一个词），字体偏好等等（比如通过 session,cookie,webstorage 等），可以理解这是针对域名来对这些数据分开隔离的），所谓大家都在说，不允许带 cookie 啥的。 但是忽略了我的原始问题，不同网站的凭证可能是不同方式实现的，是业务自己私密的实现。这个也不属于标准或协议层面。


**当响应的是附带身份凭证的请求时，服务端必须明确 Access-Control-Allow-Origin 的值，而不能使用通配符“*”。**

协议或者说浏览器要求带这个头部之类的，他怎么判断这个是不是普通请求呢？有些请求里面有 cookie 不代表这是带凭证吧。
@GeruzoniAnsasu

问过了，并不到位，甚至会乱回答。

firefox 自带，可以试试

实用

MIT 6.824 ， 值得学一学

@RaMa291041610 他微博多少啊？

@PeneceaQwQ 增量备份怎么搞啊

@RaMa291041610 你可以联系他吗？他的 fancypig 都访问不了，请问还维护吗？

你这博客广告也太多了