最近在建設(shè)websocket長連接網(wǎng)關(guān)，過程中遇到一件比較奇怪的事情，做下簡單的記錄。

需求十分的簡單，websocket網(wǎng)關(guān)在做權(quán)限校驗(yàn)的時(shí)候期望復(fù)用現(xiàn)有登錄邏輯的jwt-token。如下圖所示，sso與websocket網(wǎng)關(guān)屬于不同的二級(jí)域名，登錄的jwt-token cookie的domain設(shè)置為*.xx.com。所以我們的期望是瀏覽器與websocket網(wǎng)關(guān)進(jìn)行handshark請(qǐng)求時(shí)可以帶上jwt-token cookie。

image

結(jié)果自然是不行的，服務(wù)端并沒有收到來自*.xx.com的cookie。于是開始考慮可能和跨域行為有關(guān)系。

CORS

CORS 是一種用于解決跨域的w3c標(biāo)準(zhǔn)，全稱為"跨域資源共享"(Cross-origin resource sharing)。它允許瀏覽器向跨源服務(wù)器，發(fā)出 XMLHttpRequest 請(qǐng)求，從而克服了 AJAX 只能同源使用的限制。CORS 基于 http 協(xié)議關(guān)于跨域方面的規(guī)定，使用時(shí)，客戶端瀏覽器直接異步請(qǐng)求被調(diào)用端服務(wù)端，在響應(yīng)頭增加響應(yīng)的字段，告訴瀏覽器后臺(tái)允許跨域。

概括的說，CORS就是服務(wù)端對(duì)跨域權(quán)限的控制，由一組標(biāo)準(zhǔn)的header來控制客戶端的跨域行為，不同瀏覽器對(duì)于CORS的實(shí)現(xiàn)均有不同。

常用的CORS header主要有：

• Access-Control-Allow-Origin ： 指示請(qǐng)求的資源能共享給哪些域，可以是具體的域名或者*表示所有域。
• Access-Control-Allow-Credentials ： 指示當(dāng)請(qǐng)求的憑證標(biāo)記為 true 時(shí)，是否響應(yīng)該請(qǐng)求。
• Access-Control-Allow-Headers ： 用在對(duì)預(yù)請(qǐng)求的響應(yīng)中，指示實(shí)際的請(qǐng)求中可以使用哪些 HTTP 頭。
• Access-Control-Allow-Methods： 指定對(duì)預(yù)請(qǐng)求的響應(yīng)中，哪些 HTTP 方法允許訪問請(qǐng)求的資源。

CORS處理請(qǐng)求的流程如下：

1. 判斷當(dāng)前請(qǐng)求是否簡單請(qǐng)求。
2. 如果不是簡單請(qǐng)求，則會(huì)使用OPTIONS方法先發(fā)起一個(gè)預(yù)檢請(qǐng)求(PreFlight)，預(yù)檢請(qǐng)求通過返回的response里設(shè)置了對(duì)應(yīng)的header并匹配上了才會(huì)進(jìn)行下一步具體的請(qǐng)求。
3. 預(yù)檢請(qǐng)求后會(huì)發(fā)起實(shí)際請(qǐng)求，但會(huì)根據(jù)返回的response header來決定請(qǐng)求行為，例如根據(jù)服務(wù)端設(shè)置的Access-Control-Allow-Credentials值來決定請(qǐng)求是否攜帶當(dāng)前域的cookie。

這里涉及到的簡單請(qǐng)求和非簡單請(qǐng)求的概念，那么簡單請(qǐng)求和非簡單請(qǐng)求有什么區(qū)別呢？若請(qǐng)求滿足所有下述條件，則該請(qǐng)求可視為簡單請(qǐng)求：

1. 使用了下列 HTTP 方法：GET、HEAD、POST。
2. 只用了以下header：Accept、Accept-Language、Content-Language、Content-Type(有額外限制)、DPR、Downlink、Save-Data、Viewport-Width、Width。
3. 請(qǐng)求中的任意XMLHttpRequestUpload 對(duì)象均沒有注冊任何事件監(jiān)聽器；XMLHttpRequestUpload 對(duì)象可以使用 XMLHttpRequest.upload 屬性訪問。
4. 請(qǐng)求中沒有使用 ReadableStream 對(duì)象。

經(jīng)過一番簡單的科普，回到我們的問題上來。瀏覽器對(duì)websocket的handshark請(qǐng)求會(huì)不會(huì)應(yīng)用同源策略呢。我們先不回答，先來看看如果CORS應(yīng)用在websocket上會(huì)是什么樣的。

首先一個(gè)websocket的握手連接報(bào)文大概如下：

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請(qǐng)求的區(qū)別是多了兩行header

Upgrade: websocket
Connection: Upgrade

顯然它們不屬于CORS安全的header集合，自然瀏覽器會(huì)認(rèn)為這不是一個(gè)"簡單請(qǐng)求"。那么它會(huì)按照發(fā)起"預(yù)檢請(qǐng)求"，隨后根據(jù)返回的response header來判斷下一步行為。此處我們希望能帶上當(dāng)前域的cookie，那么按照CORS標(biāo)準(zhǔn)，我們需要在服務(wù)端做一些配置，讓其支持CORS并帶上Access-Control-Allow-Credentials為true的response header。

我們使用的是Netty來構(gòu)建websocket網(wǎng)關(guān)，Netty支持CORS很簡單：

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

結(jié)果是什么呢？我們的websocket服務(wù)端正確拿到了*.xx.com的cookie，并完成了后續(xù)鑒權(quán)工作。

websocket需要CORS么？

所以真相是什么呢？websocket也需要CORS支持來避免跨域問題么？

google任何websocket與跨域相關(guān)的問題都會(huì)告訴你，websocket本身就是支持跨域的，websocket本身沒有同源策略！也就是說，在第一幅圖中，我們應(yīng)該不作任何事就可以把www.xx.com的cookie帶到ws.xx.com的websocket網(wǎng)關(guān)上去，這似乎和我們實(shí)際情況不符。

我們使用的是chrome，后來突發(fā)奇想試了下firefox與safari，結(jié)論是這兩者不用配置任何CORS相關(guān)屬性就可以把cookie帶上。難道這是chrome的一個(gè)bug?翻了翻網(wǎng)絡(luò)，找到了一個(gè)似乎可以應(yīng)征的bug report: Cookies not sent in Websocket handshake with cookies blocked and domain whitelisted