[[376527]]

當我們寫好SSO單點登錄服務的代碼后，通過調用接口方式驗證，流程看似正常，但開始與前端聯調就出現問題了。

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

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

關于ajax無法攔截302處理的原因，筆者從網上找到的解釋如下。

服務器將302響應發給瀏覽器時，瀏覽器并不是直接進行ajax回調處理，而是先執行302重定向，從響應頭中讀取Location信息，然后向Location中的Url發出請求，在收到這個請求的響應后才會進行ajax回調處理。

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

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

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

流程修改后，當后端驗證用戶未登錄或登錄過期時響應401狀態碼，同時body給出重定向鏈接，而前端需要全局攔截401錯誤，從響應body獲取鏈接并讓瀏覽器重定向到指定鏈接，該鏈接就是由后端拼接好的跳轉到SSO登錄的鏈接。

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

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

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

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

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

 本文轉載自微信公眾號「Java藝術」，可以通過以下二維碼關注。轉載本文請聯系Java藝術公眾號。