蘋果cookie是打開還是關閉_cookie那些事

cookie的誕生

HTTP無狀态：伺服器無法知道兩個請求是否來自同一個浏覽器，即伺服器不知道使用者上一次做了什麼，每次請求都是完全互相獨立

互動式Web：用戶端與伺服器可以互動，如使用者登入，購買商品，各種論壇等等

Cookie的誕生是為了解決HTTP無狀态的特性無法滿足互動式web

cookie互動原理

1、使用者在輸入使用者名和密碼之後，浏覽器将使用者名和密碼發送給伺服器，伺服器進行驗證，驗證通過之後将使用者資訊加密後封裝成Cookie放在請求頭中傳回給浏覽器。

2、浏覽器收到伺服器傳回資料，發現請求頭中有一個：Set-Cookie，然後它就把這個Cookie儲存起來，下次浏覽器再請求伺服器的時候，會把Cookie也放在請求頭中傳給伺服器

3、伺服器收到請求後從請求頭中拿到cookie，然後解析并到使用者資訊，說明此使用者已登入，Cookie是将資料儲存在用戶端的

cookie屬性

屬性	描述
HttpOnly	标記為 Secure 的 Cookie 隻應通過被HTTPS協定加密過的請求發送給服務端。使用 HTTPS 安全協定，可以保護 Cookie 在浏覽器和 Web 伺服器間的傳輸過程中不被竊取和篡改
Secure	如果一個cookie被設定了Secure=true，那麼這個cookie隻能用https協定發送給伺服器，用http協定是不發送的
Domain	Domain 指定了 Cookie 可以送達的主機名。假如沒有指定，那麼預設值為目前文檔通路位址中的主機部分(但是不包含子域名)。 像淘寶首頁設定的 Domain 就是 .taobao.com，這樣無論是 a.taobao.com 還是 b.taobao.com 都可以使用 Cookie。 在這裡注意的是，不能跨域設定 Cookie，比如阿裡域名下的頁面把 Domain 設定成百度是無效的
Path	Path 指定了一個 URL 路徑，這個路徑必須出現在要請求的資源的路徑中才可以發送 Cookie 。比如設定  Path=/docs ， /docs/Web/  下的資源會帶 Cookie 首部， /test  則不會攜帶 Cookie 首部。 Domain 和 Path 辨別共同定義了 Cookie 的作用域：即 Cookie 應該發送給哪些 URL
Expires	當 Expires 屬性預設時，表示是會話性 Cookie，像上圖 Expires 的值為 Session，表示的就是會話性 Cookie。當為會話性 Cookie 的時候，值儲存在用戶端記憶體中，并在使用者關閉浏覽器時失效。需要注意的是，有些浏覽器提供了會話恢複功能，這種情況下即使關閉了浏覽器，會話性 Cookie 也會被保留下來，就好像浏覽器從來沒有關閉一樣。 與會話性 Cookie 相對的是持久性 Cookie，持久性 Cookies 會儲存在使用者的硬碟中，直至過期或者清除 Cookie。這裡值得注意的是，設定的日期和時間隻與用戶端相關，而不是服務端
SameSite	SameSite 屬性可以讓 Cookie 在跨站請求時不會被發送，進而可以阻止跨站請求僞造攻擊(CSRF)

重定向原理

用戶端向伺服器發送請求的時候,伺服器如果重定向的話,傳回狀态碼301或者302給用戶端,在響應頭中存放location,location對應的值就是重定向位址,用戶端收到狀态碼為重定向,直接浏覽器本地進行通路

一次線上問題排查過程

問題現象：

企業微信A企業，內建兩個移動審批，分别使用wx_third和multi_wx3，在企業微信中交替通路兩個移動審批，發現其中一個沒有走對應內建方案的單點登入，比如打開multi_wx3的移動審批，實際url位址中的為wx_third，并且實際換取到使用者身份也不是實際的值

移動計劃在同場景下的資料互動執行個體

摘要

1、URL:https://qy-ci.fdccloud.com/appcenter/dispatch/open?__tenant_id=my59844a86a6053&__wx_menu_id=54&__from=wx_third 2、URL:https://qy-ci.fdccloud.com/plan-  micro/my59844a86a6053/task/home/index?__from=wx_third 3、URL:https://qy-ci.fdccloud.com/plan-micro/my59844a86a6053/task/home/index?__from=wx_third 4、URL:https://qy-ci.fdccloud.com/plan-micro/my59844a86a6053/schedule/calendar/index?__from=wx_third#/message/index

批注：

1、請求分發位址dispatch/open，服務端告訴浏覽器需要要重定向到真實的計劃位址

2、浏覽器開始請求真實的計劃位址，服務端發現_from參數與cookie不一緻，強制登出，并告訴浏覽器再次重定向到目前頁面，服務端同時設定了最新的cookie值與_from參數一緻

3、浏覽器再次請求計劃的真實位址，同時攜帶了最新的cookie，重新進行了免登，移動計劃再次告訴浏覽器需要再次做重定向到計劃的消息頁面

4、浏覽器開始請求計劃的消息頁面

移動審批在同場景下的資料互動執行個體

摘要

1、URL: https://qy-ci.fdccloud.com/appcenter/dispatch/open?__tenant_id=my59844a86a6053&__wx_menu_id=130&__from=multi_wx3

2、URL: http://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/workflow/process-list/index?kindType=1&status=0&__from=multi_wx3

3、URL: http://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/lists/process-list/index?kindType=1&status=0&__from=multi_wx3

4、URL: https://qy-ci.fdccloud.com/workflow-micro/my59844a86a6053/lists/process-list/index?kindType=1&status=0&__from=multi_wx3

批注：

1、請求分發位址dispatch/open，服務端告訴浏覽器需要要重定向到真實的審批位址

2、浏覽器開始請求真實的審批位址，移動審批在actions()方法中攔截到了目前是新服務，然後告訴浏覽器要重定向到

新服務位址

3、浏覽器開始請求移動審批的新服務位址，此時vendor beforeAction()檢測到目前請求的位址是http協定，告訴浏覽器需要重定向到https，并且把最新的cookie傳回給了浏覽器

4、浏覽器開始請求https的審批位址，直接進入了應用，前面沒有做任何登出，也不滿足_from參數和cookie的值不一緻，此時的使用者實際身份還是上一個內建方案對應的使用者

總結：

為何審批的執行流程和計劃相差這麼大，正是這個差别導緻計劃表現正常而審批發生串号的問題所在。

問題根源在于我們期望是在beforeAction()中實作檢測__from的變更，進而實作登出，通過重定向再次登入的邏輯。但是審批比較特殊，他們在幾個重要的控制器中重寫了actions()方法，他們也會做重定向，而且actions()是在beforeAtion()之前執行的，最新的cookie已經被審批傳回給浏覽器了，下次再進入最終的審批頁面時，beforeAction()是檢測不到變更的，自然也實作不了登出再重新登入