作者：fredalxin

地址：https://fredal.xin/websocket-...

最近在建设websocket长连贯网关，过程中遇到一件比拟奇怪的事件，做下简略的记录。

需要非常的简略，websocket网关在做权限校验的时候冀望复用现有登录逻辑的jwt-token。如下图所示，sso与websocket网关属于不同的二级域名，登录的jwt-token cookie的domain设置为*.xx.com。

所以咱们的冀望是浏览器与websocket网关进行handshark申请时能够带上jwt-token cookie。

后果天然是不行的，服务端并没有收到来自*.xx.com的cookie。于是开始思考可能和跨域行为有关系。

CORS

CORS 是一种用于解决跨域的w3c规范，全称为"跨域资源共享"(Cross-origin resource sharing)。它容许浏览器向跨源服务器，收回 XMLHttpRequest 申请，从而克服了 AJAX 只能同源应用的限度。CORS 基于 http 协定对于跨域方面的规定，应用时，客户端浏览器间接异步申请被调用端服务端，在响应头减少响应的字段，通知浏览器后盾容许跨域。

概括的说，CORS就是服务端对跨域权限的管制，由一组规范的header来管制客户端的跨域行为，不同浏览器对于CORS的实现均有不同。

罕用的CORS header次要有：

  • Access-Control-Allow-Origin ： 批示申请的资源能共享给哪些域，能够是具体的域名或者*示意所有域。
  • Access-Control-Allow-Credentials ： 批示当申请的凭证标记为 true 时，是否响应该申请。
  • Access-Control-Allow-Headers ： 用在对预申请的响应中，批示理论的申请中能够应用哪些 HTTP 头。
  • Access-Control-Allow-Methods： 指定对预申请的响应中，哪些 HTTP 办法容许拜访申请的资源。

CORS解决申请的流程如下：

  1. 判断以后申请是否简略申请。
  2. 如果不是简略申请，则会应用OPTIONS办法先发动一个预检申请(PreFlight)，预检申请通过返回的response里设置了对应的header并匹配上了才会进行下一步具体的申请。
  3. 预检申请后会发动理论申请，但会依据返回的response header来决定申请行为，例如依据服务端设置的Access-Control-Allow-Credentials值来决定申请是否携带以后域的cookie。

这里波及到的简略申请和非简略申请的概念，那么简略申请和非简略申请有什么区别呢？若申请满足所有下述条件，则该申请可视为简略申请：

  1. 应用了下列 HTTP 办法：GET、HEAD、POST。
  2. 只用了以下header：Accept、Accept-Language、Content-Language、Content-Type(有额定限度)、DPR、Downlink、Save-Data、Viewport-Width、Width。
  3. 申请中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象能够应用 XMLHttpRequest.upload 属性拜访。
  4. 申请中没有应用 ReadableStream 对象。

通过一番简略的科普，回到咱们的问题上来。浏览器对websocket的handshark申请会不会利用同源策略呢。咱们先不答复，先来看看如果CORS利用在websocket上会是什么样的。

首先一个websocket的握手连贯报文大略如下：

GET / HTTP/1.1Upgrade: websocketConnection: UpgradeHost: ws.xx.comOrigin: http://www.xx.comSec-WebSocket-Key: sB9cRrP/a9NdMgdcy2VJFX==Sec-WebSocket-Version: 11

它和一般HTTP申请的区别是多了两行header

Upgrade: websocketConnection: Upgrade

显然它们不属于CORS平安的header汇合，天然浏览器会认为这不是一个"简略申请"。那么它会依照发动"预检申请"，随后依据返回的response header来判断下一步行为。此处咱们心愿能带上以后域的cookie，那么依照CORS规范，咱们须要在服务端做一些配置，让其反对CORS并带上Access-Control-Allow-Credentials为true的response header。

咱们应用的是Netty来构建websocket网关，Netty反对CORS很简略：

CorsConfig corsConfig = CorsConfigBuilder.forAnyOrigin().allowNullOrigin().allowCredentials().build();pipeline.addLast(new CorsHandler(corsConfig));

后果是什么呢？咱们的websocket服务端正确拿到了*.xx.com的cookie，并实现了后续鉴权工作。

websocket须要CORS么？

所以假相是什么呢？websocket也须要CORS反对来防止跨域问题么？

google任何websocket与跨域相干的问题都会通知你，websocket自身就是反对跨域的，websocket自身没有同源策略！也就是说，在第一幅图中，咱们应该不作任何事就能够把xx.com的cookie带到ws.xx.com的websocket网关下来，这仿佛和咱们理论状况不符。

咱们应用的是chrome，起初突发奇想试了下firefox与safari，论断是这两者不必配置任何CORS相干属性就能够把cookie带上。难道这是chrome的一个bug?翻了翻网络，找到了一个仿佛能够应征的bug report：https://bugs.chromium.org/p/c...

近期热文举荐：

1.600+ 道 Java面试题及答案整顿(2021最新版)

2.终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！