KK 的 Web 實驗室(Day17–19)
KK 是認真的男人，週三不能吃火鍋，我不是但我也不能吃
21 成為看起來很強的後端：什麼是 Session？
KK 老師之前帶我們認識各種 HTTP 的驗證模式。
接下來要談一個很有名的模式： Session 。
什麼是 Session ？
很多地方的翻譯不太一樣，常見的稱作「會話/對話」。
KK 舉例，小明、小王兩個人各走在路上，突然看到彼此。
這時候 Session 就開始了。
彼此互相說了聲好、聊聊天氣、約了之後要吃飯然後就說了再見。
此時 Session 就結束了。
可以想成：
Session 是開始到結束這「一段時間內」，所存的「狀態」。
各位有沒有一個經驗，有些網站會突然把你登出，並顯示「工作階段已過期」。
例如：使用網路銀行，登入之後，網頁會顯示一個倒數計時器，在時間到後強制登出。
或是當我們打開一個新的網頁分頁，也可以視為分頁的 Session 開始，之後關掉分頁，Session 就結束。
點開瀏覽器之後，瀏覽器的 Session 開始，使用後關閉瀏覽器，瀏覽器的 Session 結束。
總之，Session 是一個之後會持續用到的概念，並不是一個特定的實作方式。
為什麼 Session 這觀念很重要？
前面談過 HTTP ，包含 Header 和 Body ，是屬於「沒有狀態性」的模型。
當 Client 端「第一次」透過 HTTP 發請求給 Server ，Server 給予 Response。
而 Client 端 「第二次」透過 HTTP 發請求給 Server ， Server 給予 Response 。
「第一次」和「第二次」之間是完全無關的，在 HTTP 裡屬於「無狀態」的請求。
因此，每一次瀏覽器到另外一個頁面，就必須重新再次登入。
而我們想要的，是將使用者的登入狀態存起來。不管發送幾次請求，都還是在登入狀態。
之前提到 JWT 的時候，在登入的時候，Client 端會拿到一個 Server 回傳的 token 。
只要我們有 token 就能保持登入。
那如果不使用 token 呢？
我們可以透過瀏覽器內建的 Cookie 機制。
22 成為看起來很強的後端：Cookie 運作方式
Cookie 為什麼叫做 Cookie ？
KK 老師說一個說法是，餅乾是一片一片的小東西，就像是被儲存的小資料。
另外一個說法是，以前有一個吃餅乾的遊戲，裡面的餅乾叫做 Magic Cookie ，就像是魔法餅乾一樣，可以把資料儲存起來。
（突然好想吃餅乾， Aunt Stella’s 或是 Subway 都好。不過 Wikipedia 這邊關於起源也有一些描述，可以參考。https://en.wikipedia.org/wiki/HTTP_cookie#Origin_of_the_name。也在另外一個地方看到也可能是國外中餐廳飯後很愛給的 Fortune Cookie 這樣的意思，因為每個 Cookie 裡面都有一點資訊。）
簡單說： Cookie 是「儲存在瀏覽器」裡面的「小份資料」。
（為什麼特別強調是「小份資料」，是因為之後會介紹一個「大份資料」，HTML5 的 local storage 。）
Cookie 怎麼運作？
KK 舉了個例子，假想每天去早餐店都吃固定的餐點。
我們要如何在下一次吃早餐的時候，不用點餐，早餐店就知道我要點什麼？
那假設我早餐想喝紅茶好了。
Browser (瀏覽器) 「第一次」使用 /login 發送 Request 連到 Server，Server 回傳的 Response Header 裡有個 Set-Cookie: 早餐=紅茶。
Browser 收到這個 Set-Cookie ，會幫你把「早餐=紅茶」存起來。（限制只能存 4kb 的字串，因此不能存太大的資料。）
Browser 在「第二次」發送 Request 時，就會自動在 Request Header 裡帶著 Cookie: 早餐=紅茶。
這樣我們不用額外帶資料，Server 就知道我們的 早餐=紅茶。
這個舉例如果不是很直覺，我們用原先使用 Cookie 的主要目的「登入」再過一次。
Browser (瀏覽器) 「第一次」使用 /login 發送 Request 連到 Server，Server 回傳的 Response Header 裡有個 Set-Cookie: login=true。
Browser 收到這個 Set-Cookie ，會幫你把「login=true」存起來。
Browser 在「第二次」發送 Request 時，就會自動在 Request Header 裡帶著 Cookie: login=true。
這樣我們不用額外帶資料，Server 就知道我們的「login=true」。
因此就能保持登入狀態了。
Cookie 跟 token 比起來有什麼好處？
使用 token 就需注意保存的安全，之前談 JWT 的時候有討論過。
而瀏覽器會自動把 Cookie 存起來，確保安全性，因此在寫程式的時候不用特別寫這塊。
那 Cookie 有壞處嗎？
如果我明明沒有登入的情形下，能不能自己改 Cookie 的狀態成已經登入的狀態呢？
23 成為看起來很強的後端：Session-based Cookie v.s. Session Store
我們要如何防止 Cookie 被竄改？
如果有機密資料要如何保護？
先來談 Session-based Cookie。
如果有安全性的疑慮，之前提過幾種方法：雜湊、編碼、加密。
編碼我們先不考慮，因為是雙向的。
雜湊的話，Server 會無法解析 Cookie 的內容，僅能驗證是否為正確的。
所以通常會使用「加密」的方式。
Server 回傳的時候先把 login=true 給加密變成 xxxxxx。
Browser 存起來也是 xxxxxx ， 下一次 Request 自動帶的 Cookie 也是 xxxxxx 。
此時 Server 再把 xxxxxx 解密，就能知道 Cookie 裡面存的是什麼。
這就是 Session-based Cookie 。
Session-based Cookie 會遇到什麼問題？
第一個問題
加密跟解密都需要額外的處理時間。
第二個問題
加密之後長度會變比較長，Cookie 限制可能無法存。
第三個問題
瀏覽器存了，也有被破解的風險。
因此有了比較常見的第二種模式， Session data。
延續前面早餐店的例子，每天去早餐店都想吃固定的餐點。
早餐店有台機器，第一次點餐後，會根據你的點餐內容發一個號碼牌給你。
之後只要帶這個號碼牌去，早餐店就知道你吃的是什麼。
如果別人撿到你的號碼牌也無法知道代表什麼意思。
因此我們改把資料存在 Server 端，不存在 Client 端。
Server 會把這些 Session data 存在 Session store 裡面。
Session data 模式怎麼做呢？
Browser「第一次」使用 /login 發送 Request 連到 Server，Server 回傳的 Response Header 裡有個 Set-Cookie: sid=001。
(這邊回傳的 id 可能叫 sid 或 cid …等等，如果使用 Chrome 可以去瀏覽器左上方的鎖頭點一下，就能看到 Cookies 的資訊。)
Browser 在「第二次」發送 Request 時，就會自動在 Request Header 裡帶著 Cookie: sid=001。
Server 看到 sid=001 之後就會去 Session store 確認資料是否正確，OK 的話就回傳資料。
Session data 模式的好處，就在於實際的資料並不會進行傳輸。
伺服器可以隨時註銷 Session ID ，這樣就算瀏覽器端就會被自動登出。
現在大都採用 Session data 的模式來提高安全性。
那 Session ID 要怎麼產生呢？
大部分的情況都是使用 Session store ID 的產法。
有時候會用 Redis，有些人會存在 Disk 裡面或用 Memcached 。
而通常都是亂碼的字串，所以不會像 001 這樣漂亮的數字。
總結 Cookie 到 Session-based Cookie 到 Session data 的重點：
為了保持登入的 session 狀態，原本的 Cookie 會在瀏覽器紀錄部分的資訊。
後來發現這些資料可能會被看到，因此進行加密。
加密也可能被解密或字串超過 Cookie 限制，而有了 Session data 的模式。
之後會針對 Cookie 做更多解釋，請大家繼續支持 KK 的鐵人賽！
