[[376527]]

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

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

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

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

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

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

原本是為了讓前端以最少的改動(dòng)接入SSO，但因?yàn)楣P者對(duì)前端的了解較淺，才犯了這樣的錯(cuò)誤。

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

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

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

原因在上篇已經(jīng)描述過(guò)了，就是因?yàn)橛蛎煌?，前端使用ajax發(fā)起請(qǐng)求，瀏覽器并不會(huì)將xxx.com域名下的cookie帶上，只會(huì)帶上127.0.0.1域名下的cookie。

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

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

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

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