乐趣区

关于java:关于-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 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

退出移动版