[[376527]]

當(dāng)我們寫好SSO單點登錄服務(wù)的代碼后，通過調(diào)用接口方式驗證，流程看似正常，但開始與前端聯(lián)調(diào)就出現(xiàn)問題了。

流程是這樣的：前端在首頁使用ajax訪問后端獲取菜單或者用戶信息的接口，以觸發(fā)登錄校驗，如果未登錄則重定向到SSO登錄頁面。

但這一步就出問題了，原因是ajax無法攔截302處理。當(dāng)ajax接收到302響應(yīng)時，看起來就像是ajax直接向重定向鏈接發(fā)起請求，而不是讓瀏覽器重定向，結(jié)果啥事也沒干。

關(guān)于ajax無法攔截302處理的原因，筆者從網(wǎng)上找到的解釋如下。

服務(wù)器將302響應(yīng)發(fā)給瀏覽器時，瀏覽器并不是直接進行ajax回調(diào)處理，而是先執(zhí)行302重定向，從響應(yīng)頭中讀取Location信息，然后向Location中的Url發(fā)出請求，在收到這個請求的響應(yīng)后才會進行ajax回調(diào)處理。

大致流程：ajax -> browser -> server -> 302 -> browser(redirect) -> server -> browser -> ajax callback。

原本是為了讓前端以最少的改動接入SSO，但因為筆者對前端的了解較淺，才犯了這樣的錯誤。

既然ajax無法處理302，那也只能修改流程，讓前端主動發(fā)起重定向了。

流程修改后，當(dāng)后端驗證用戶未登錄或登錄過期時響應(yīng)401狀態(tài)碼，同時body給出重定向鏈接，而前端需要全局?jǐn)r截401錯誤，從響應(yīng)body獲取鏈接并讓瀏覽器重定向到指定鏈接，該鏈接就是由后端拼接好的跳轉(zhuǎn)到SSO登錄的鏈接。

最后還有一個cookie問題。由于本地測試，前端將請求轉(zhuǎn)發(fā)給部署到測試環(huán)境的后端，前端的域名為127.0.0.1，后端測試環(huán)境域名為xxx. com，導(dǎo)致本地測試跳轉(zhuǎn)到SSO登錄成功并返回后，前端向后端發(fā)起請求依然響應(yīng)401。

原因在上篇已經(jīng)描述過了，就是因為域名不同，前端使用ajax發(fā)起請求，瀏覽器并不會將xxx.com域名下的cookie帶上，只會帶上127.0.0.1域名下的cookie。

解決該問題只需要修改傳給SSO登錄成功后重定向的checkToken接口的域名為前端本地測試的域名，由前端將請求轉(zhuǎn)發(fā)給后端，或者在nginx配置將此接口的請求轉(zhuǎn)發(fā)給后端處理，只有這樣session才能保持一致。

除此之外，跨協(xié)議無法重訂向。也就是說，sso部署在測試環(huán)境域名為https://sso.xx.com，而接入sso的服務(wù)在本地測試域名為http://127.0.0.1，想要從https://sso.xx.com登錄成功后重定向回http://127.0.0.1是不支持的，原因是跨協(xié)議重定向了，由https協(xié)議變成了http協(xié)議。

從這些事情可以看出，實戰(zhàn)很重要!即便理解了流程、實現(xiàn)原理，但不動手實戰(zhàn)就學(xué)不到細(xì)節(jié)，無法從各種踩坑過程中成長。

 本文轉(zhuǎn)載自微信公眾號「Java藝術(shù)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號。