关于 websocket 跨域的一个奇怪问题…

做者：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.1

Upgrade: websocket

Connection: Upgrade

Host: ws.xx.com

Origin: http://www.xx.com

Sec-WebSocket-Key: sB9cRrP/a9NdMgdcy2VJFX==

Sec-WebSocket-Version: 11

它和普通HTTP请求的区别是多了两行header

Upgrade: websocket

Connection: 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开发手册（嵩山版）》最新发布，速速下载！

以为不错，别忘了随手点赞+转发哦！