[筆記]深入HTTP 中的 Cookie
先了解什麼是 Session ->為一段「時間」內發生的「狀態」
Session → 一段「時間」內發生的「狀態」
Session是一個概念
ex ：
當我們啟動瀏覽器打開一個分頁，我們可以說這個分頁的Session開始
到我們最後把分頁關閉，這個分頁的 Session結束
因為HTTP 是無狀態的 ->無法保存使用者的資訊
舉例：若在第一個網頁登入成功 到下個網頁就被登出
問題來了 — 如何追蹤使用者的Session ？
利用瀏覽器內建的機制cookie將狀態保留
常用兩種用於追蹤使用者Session技術
一個是 Cookie，而另一個是 Session
Cookie / Session
Session 這裡為會話控制或是保持狀態
Cookie / Session區別
Cookie 是透過客戶端紀錄訊息確定使用者身份
Session 是透過在伺服器端紀錄訊息確定使用者身份
而 Session 的實現是依賴於 Cookie , (session id的唯一標誌要放在客戶端)
Cookie的運作機制
Cookie 為 儲存在瀏覽器的小份資料
儲存狀態模型
第一次請求 Browse → Server
第一次回應 Browse < — Server
Server response Header set Cookie (key :value)
第二次請求 Browse -> Server
Request Header Cookie (key :value)
第二次請求 Browse -> Server
Request Header Cookie (key :value)
Server 收到 發現帶cookie 通過驗證 可以直接給該使用者資訊
Browse<-Server
在第一次請求時，將資訊紀錄起來
在接下來的請求帶著紀錄的資訊．
Cookie
好處 自動把Cookie存在瀏覽器 (vs Token(需要自己手動把Token存起來)
不需要特別寫如何將cookie存到瀏覽器
壞處 客戶端可能竄改
如何防範
1. Cookie-based session(cookie加密之後做傳輸)
基於Session的概念 以純Cookie的方式去做
加密用cookie的方式去模擬session機制
無法儲存大份資料(因為Cookie只能存4k)
(目前少用)
Session
彌補 純Cookie 的不足
2.Session Store (狀態資訊是直接存在 Server 端存靠 SessionID )
因此 Session 是依賴於 Cookie的！
Server在第一次生成對象儲存資料資料存進
Session Data(Session Store 儲存Session物件的地方) 設置Session id
回應 Session id 於cookie
客戶端 第二次的請求帶上sid;
server端跟SessionStore 確認 判斷sid 正確 給予資料
帶來好處
安全性 因為不要直接去傳資料 (傳的是序號)
像是發號碼牌 號碼牌掉了也不用擔心
號碼牌只有在兌換的時候才會看到要兌換的東西
Cookie 三階段
單純存資料 — > 加密 — >SessionData
重點Tip:
- Cookie 數據放在客戶端瀏覽器 Session 數據放在伺服器
- Cookie 較不安全 可能被竄改 Session 較安全
- Session會在Server保存一定時間，因此會佔用性能
- 單個cookie不可以超過4k 瀏覽器站點不能超過20個
個人使用：重要訊息放在Session當中 其他訊息放cookie
參考資料
