這是一次關(guān)于服務(wù)器session丟失原因的排查、分析和解決方案的整理
環(huán)境描述
自從app的2.2 版本上線以來，就有一個問題困擾著我，那就是我們的測試環(huán)境session丟失問題。但正是環(huán)境卻不會發(fā)生，所以這個問題就一直拖著了。而正式環(huán)境和測試環(huán)境唯一的差別就是：測試環(huán)境使用的是IP地址，并且其中商城模塊（做web請求的主要頁面）和普通接口請求（API）共用相同的IP地址，只是端口不同，正式環(huán)境中商城的web請求和 API 請求使用域名服務(wù)器。API的每次請求，都會保證當(dāng)前處于登陸狀態(tài)，如果沒有登陸狀態(tài)，那么會自動登陸，并且返回session，每次請求的登陸狀態(tài)驗證。如果客戶端發(fā)送請求中所帶的session和服務(wù)器不一致，那就是未登錄狀態(tài)，從而要自動重新登陸。
問題發(fā)生
在測試環(huán)境中，從app頁面，進(jìn)入到商城（商城是作為整個客戶端的一個小模塊，主要是web頁面通過JS 與本地APP進(jìn)行交互。商城獨立運營）。在商城中操作，知道需要調(diào)用原生的充值功能，在充值成功之后，通過OC的UIWebView的借口，調(diào)用商城的JS方法，達(dá)到刷新進(jìn)入原生充值頁面之前的web頁面。但問題就是在這個時候發(fā)生，當(dāng)我通過web view調(diào)用js 的recharge方法時候，商城后臺接收到了方法，并且也調(diào)用了更新webview 頁面的方法，但是，在客戶端，沒有接收到webview的更新，也就是說，他們雖然調(diào)用了方法，但實際上這個方法在執(zhí)行過程中，是失敗的，沒有達(dá)到目的。通過調(diào)試，發(fā)現(xiàn)商城的session（商城和API請求使用不同的session）丟失了。所以webview的重新渲染是沒有發(fā)生的。
分析原因
我試著google 找了一些關(guān)于cookie的知識，然后通過apple的文檔，了解了apple中關(guān)于cookie的文檔，發(fā)現(xiàn)對于cookie而言，只要其名字，域名，和保存路徑相同，那么后一次寫入的cookie就會覆蓋前一次的。既然這樣，我嘗試著自己來改變cookie，自己設(shè)定他們的名字，再向服務(wù)器提交請求，但請求之后再回來看cookie，又變回默認(rèn)的名字。那就可以推斷是服務(wù)器將請求發(fā)送過去的cookie信息重寫了，所以我這邊怎么改變都是沒用的。這個時候，我開始與商城中做前段的同事強哥交流請教，（強哥之前是做服務(wù)器段的，所以服務(wù)器那段的他都是知道的）。因為商城web請求與API請求的服務(wù)器都是使用IP地址，只是端口不同，那問題就在端口上了，應(yīng)該是后臺服務(wù)器在向app端傳遞cookie時候，沒有加上端口的處理，所以不管是商城請求還是API請求，后一次的cookie都會覆蓋前一次的cookie，具體到app里，那就是從app 進(jìn)入到商城模塊，這個時候，商城的cookie覆蓋了API的cookie，然后從商城進(jìn)入充值，在完成充值請求的時候，app發(fā)現(xiàn)cookie中的session與服務(wù)器不一致，于是app重新登陸，這個時候，商城的cookie又被API的cookie覆寫。也就是商城的session丟失了。當(dāng)充值完成之后，app端調(diào)用商城后臺的js 方法更新web的頁面，這個時候，帶到商城后臺去的cookie，實際上是API的cookie，所以造成了調(diào)用失敗，無法更新app端的UI。
解決問題
解決問題的方法，那就針對相同的域名/IP地址，在使用不同端口劃分模塊時候，修改服務(wù)器的配置，使兩個功能模塊的cookie能區(qū)分開來。具體的處理，這得跟后臺交流，也可以參考這里。
總結(jié)
- 這個問題在正式環(huán)境一般都不會發(fā)生的，但問題的原因確實是需要了解的
- 解決問題的一般步驟如上，確定變量，抓住問題，進(jìn)行分析，尋求解決方案，最后別忘了做個記錄，別掉進(jìn)相同的坑兩次。
- 交流，很多問題并非是app端的問題，像本文章的問題，所以積極的交流才能讓自己少做彎路，更何況，交流中你就自然而然學(xué)到了不少東西。
- 在向別人尋求幫助之前，應(yīng)該先自己想想，通過搜索引擎尋求方法，因為你遇到的問題，很多人都遇到過。
