我当前有多个二级域名的项目:a.sampleDemain.com b.sampleDemain.com c.sampleDemain.com 我的登录页面是user.sampledemain.com,登录成功后我把cookie放到了sampledemain.com这个domain下，我希望a.sampleDemain.com b.sampleDemain.com c.sampleDemain.com这些网站都能提交cookie到user.sampledemain.com这个服务做一些数据获取处理，但是我试了一下，我的服务器端Access-Control-Allow-Origin不能设置成通配符：*.sampleDemain.com,必须指定具体的二级域名，否则cookie服务器端就获取不了。这个有什么好的解决方案吗？ Access-Control-Allow-Origin：http://a.sampleDemain.com Access-Control-Allow-Credentials：true Access-Control-Allow-Headers：Content-Type,X-Requested-With Access-Control-Allow-Methods：GET, POST, PATCH, PUT, DELETE, OPTIONS Cache-Control:no-store 如果这么设置只有a.sampleDemain.com，能正常处理，b.sampleDemain.com c.sampleDemain.com就会出现跨域错误

作者回复: 二级域名通配特不被直接支持，通常服务器配置都支持if、map等语法，通过这些语法对请求中的Origin头部值匹配成功后，实时构造Access-Control-Allow-Origin是一种解决方案。例如如果你是Nginx可以参考：http://joinyoo.com/2017/06/set-access-control-allow-origin-wildcard-subdomains-to-make-cors-safer/

2019-06-06



2

这节课有以下几个问题不太理解, 希望老师帮忙解答一下: 1. 预检请求是不是preflight, 而不是prefilght 2. Content-Type: application/json;charset=UTF-8或application/xml;charset=UTF-8 这样的请求是不是都是复杂请求? 3. 在预检请求的响应头部中 Access-Control-Max-Age 表示允许缓存的最长时间, 这里的缓存是指浏览器缓存吗? 如果没有超过缓存时间, 浏览器是可以不用发起跨域请求了直接复用上次的结果吗? 4. 最后一页PPT的跨域访问资源: 响应头部中, 这些响应头部是对于preflight请求的响应还是对实际的复杂请求的响应?

作者回复: 1、是的，不好意思笔误。 2、是。 3、针对的是preflight请求。 4、二者都有。

2019-06-07



1

mojo

课件无法下载（https://github.com/geektime-geekbang/geektime-webprotocol）提示网页不存在，请问是什么原因？

作者回复: 用这个试试：https://github.com/russelltao/geektime-webprotocol

2020-01-02





ray

老师好，稍微整理一下本章内容，请老师点评。从前一直认为cors在任何请求中都会发生，这观念是错误的。 cors政策只会被浏览器所使用，如果我们使用类似postman的工具，自行发请求到server，cors就会立即失效。以下有些问题要请教老师，老师在课堂上提到response会被client缓存，我们应该如何判断一个response是否会被client缓存。 server是否可以自行决定是否要让client缓存response呢？承上，如果server预设没有设定是否让client缓存response，client是否会缓存response呢？谢谢老师的解答^^

作者回复: 1、是的； 2、RFC规范指定了一些HTTP头部，当Server发出时，Client如果收到，就应该遵守这些规范，缓存response。 3、由于互联网中有些server没有让client缓存，但浏览器的开发者从统计角度出发，仍然会缓存一些没有明确说可以缓存的response。具体参见第29-32课。

2019-11-25





小樱桃

有两个问题请教一下老师 1 为什么会有简单请求和复杂请求，应用场景有什么不同，(是不是可以都用简单请求) 2 纯nginx实现的跨域也是不规范的吗？

作者回复: 1、简单请求与复杂请求的划分依据是浏览器的风险； 2、规范与否，主要看是否针对老浏览器，即实现有bug的浏览器。如果都是你的不同域名的站点，你肯定可以基于七层负载均衡来实现的，这样做没问题的。跨域主要是担心两个不同所有者的网站互相影响。

2019-07-02





TiME

老师，对简单请求的跨域访问，有点想不通：是先对目标站点B进行跨域请求，然后靠客户端浏览器来判断原站点A是否与access-control-allow-origin相匹配来决定是否渲染。也就是说站点B已经响应跨域请求了，假如这个请求是银行转账，那不是钱已经转完了吗？渲不渲染也起不到防止攻击的作用呀！希望老师能解答一下，谢谢！

作者回复: 是的，服务器不对跨域请求做检查。没有钱转完的问题，因为域名A下的 cookie，浏览器不会带到访问域名B的请求中。

2019-06-23

6



旺旺

跨域访问除了CORS以外，是不是还有其他的办法呢？我看有的网站也是可以跨域的，但是返回的头部里没有看到Access-Control-Allow-Origin这样的头部，但是也发起了对其他域名的资源访问，这是怎么回事呢？

作者回复: 其他方法并不推荐，但是可以用，比如JSONP。针对一些老的浏览器也会因为限制不严格有更多的方式，可以参考一些文章，比如https://blog.csdn.net/ligang2585116/article/details/73072868

2019-06-14





hhk

老师, 我是前端. 现在前后端分离, 我可以修改前端nginx端配置, 我都是以反向代理来避免跨域问题的. 如果是设置cors响应头的话, 可以在我前端nginx这一层做或者叫后端接口那一层做, 我觉得都没有直接反向代理来得方便. 主要是我觉得 “Access-Control-Allow-Headers” 这个头部太麻烦了, 很有可能有些时候要根据业务情况来适时修改, 再者是复杂请求的话要走多一次预检请求感觉有点浪费, 所以请问您, 使用反向代理来解决跨域和cors来解决跨域, 有什么区别, 您更推荐哪种, 为什么呢?

2020-03-21



3

daiwf

老师，如果我在页面中要get访问127.0.0.1地址，应该怎么防止跨域拦截。chrome浏览器没有activex控件。获取mac地址的时候要访问本地。但是我看被浏览器跨域拦截了

2020-03-03





收起评论

课程相关资料下载地址

全部留言(11)