以總體思惟看問題：解決單頁應用，系統角色請求覆蓋身份惟一標識（本項目中是session_id命名的）發送請求問題

之前都是開始一段廢話的，如今直接進入主題，首先介紹一下一些概念：

單頁應用：

優勢：

1. 具備桌面應用的即時性、網站的可移植性和可訪問性。
2. 用戶體驗好、快，內容的改變不須要從新加載整個頁面，web應用更具響應性和更使人着迷。
3. 基於上面一點，SPA相對對服務器壓力小。
4. 良好的先後端分離。SPA和RESTful架構一塊兒使用，後端再也不負責模板渲染、輸出頁面工做，web前端和各類移動終端地位對等，後端API通用化。
5. 對前端人員javascript技能要求更高，促使團隊技能提高。

缺點：

1. 不利於SEO。
2. 初次加載耗時相對增多。
3. 導航不可用，若是必定要導航須要自行實現前進、後退。
4. 對開發人員技能水平、開發成本高。

多角色：項目設計中多角色參與，好比我如今作的系統，除了有我的用戶，還有開店的商戶進行登陸2種角色

session：這個很少說，後臺系統判斷用戶活躍存在的一種身份憑證。PS：如今不少大型公司都本身作session管理

 

問題再現：

1.  在一個瀏覽器中，首先使用我的用戶登陸（如今該瀏覽器針對該站點發送的請求爲我的用戶的session）
2.  而後在瀏覽器中新開一個標籤頁，一樣訪問該網址，而後安全退出，清除cookie保存的一些信息和服務器的session數據。而後使用商戶帳號進行登陸（如今整個瀏覽器針對於該域名，發送的請求都使用該商戶的session）
3. 如今切換到第一個標籤頁，是我的的首頁，而後點一個功能按鈕，監控xhr的請求，你會發現我的用戶請求的session憑據並非我的的，被商戶的標識覆蓋了，且佔用了商戶的session去發送請求

4. 這樣獲得的結果確定是錯的。因此必須解決該問題

 

測試淘寶：

• 　登陸第一個帳戶

• 新開標籤頁輸入相同網址

• 網頁會自動跳轉到和標籤也同樣的頁面

• 退出登陸新的帳號，第一個標籤頁仍是在第一我的的我的中心那裏

• 登陸第二個帳戶，這個時候第一個標籤頁是第一個帳戶的我的信息，第二個標籤頁是第二個帳戶的我的信息

• 這個時候，瀏覽器針對這個域名，其實存儲的已是第二個帳戶的全部信息了，包括session_id。因此點擊第一個標籤頁的任何操做，若是不刷新頁面的話（也就是單頁應用），會以第二個用戶的session_id去請求數據。可是淘寶是刷新整個頁面就不存在這個問題了。

• 這樣整頁刷新就是第二個帳戶的全部的信息了。若是系統多角色，並且多角色菜單啊，和業務功能不同的話，就會更明顯發現大問題，搶佔session，沒法正確請求數據

 

 

解決方案：

　　確立解決手段：通過測試淘寶網站發現，淘寶針對這種問題，每次操做都會刷新頁面，由於刷新頁面全部數據都將從新向後臺請求，因此不會存在該問題：不刷新頁面而後經過ajax一步請求數據。因此解決手段就是隻要刷新頁面所有從新請求數據就不會出現這個問題。

　　關鍵問題：怎麼去讓瀏覽 器每次去鑑別是否爲一個用戶，而後讓瀏覽器主動去刷新頁面

　　解決步驟：

1. 1. 由於問題關鍵是用戶發出的請求會被商戶的覆蓋叼，因此確認第一步在用戶每次請求的時候去檢查用戶session_id是否一致（爲同一個用戶）
   2. 在前端每次發送ajax請求的時候去檢查每次用戶登陸的時候緩存的session_id是否和當前瀏覽器登陸的用戶使用的session_id是否一致
   3. 由於安全退出的時候咱們會清除全部該域名下的cookie（這是咱們設定的規則），而後用戶登陸更新cookie，因此cookie中沒法去檢測是否一致。PS：其實在cookie中也能夠判斷，每次登陸判斷oldSession_id是否有值，沒有的話就將oldSession_id和newSession_id都設置爲該用戶的Session_id，安全退出的時候只清除newSession_id，用戶在新標籤頁再登陸的時候判斷oldSession_id的值，而後設置newSession_id的值。這樣就能夠比對了，可是咱們的規則是清除全部的cookie，因此沒辦法，這裏咱們走不通。
   4. 最後靈光一閃，想到了單頁應用的優勢：不刷新頁面，從而進行局部刷新或操做。這就表明着，單頁應用每次進行dom渲染完成以後，就不會第二次渲染整個頁面的dom，也就表明了window對象不會像每次頁面刷新重置window中的方法和對象了，那麼咱們就能夠將每次緩存當前用戶的session_id到window對象中，這樣的話，咱們每次請求的時候取到每次用戶登陸緩存的session_id和及時更新的cookie中的當前用戶的session_id進行比對，若是不同，那麼就能夠刷新頁面，整個頁面從新去請求整個數據，這樣就不會出現這樣覆蓋session_id的問題
   5. 好了，問題解決了，可是須要注意的是，每次新開一個單頁應用頁面都要緩存一下session_id這樣很繁瑣，可是沒辦法，業務規則肯定了安全退出，不留任何痕跡。繁瑣不是問題，解決問題纔不是問題

 

其實解決問題的方式有千萬種，沒有你解決不了的，只有你想不到的。程序員的路還很漫長，若是目標更大一點，架構師啊或者其餘的話，這樣的路更長。並且在職場的話，老闆不是要的你的各類阻塞的理由，而是一個結果，你解決了沒有？解決了，ok能力槓槓的，解決不了，對不起，能力還欠缺。因此，個人原則是：能作的，漂亮的解決；不能作的，評估一下，千方百計去解決，這樣才能讓老闆或者你的上司相信你，安心把事情給你作，這樣的話，老闆器重你了，升職加薪也不是問題咯。

 

分享個人全棧書籤（持續集成中）：https://github.com/GerryIsWarrior/MyBookmarks   但願點顆星，這纔是個人動力

 

我的簡介：

• 性別：男
• 愛好：女
• 目標：全棧架構師
• github:https://github.com/GerryIsWarrior