# cookie 及 session 整理

###### tags: `前端筆記`

## 起源

因為 http request 是「無狀態」的，所以對於 server 來說每個 reqeust 都是獨一無二的，換句話說 server 沒辦法藉由 http request 本身得知請求者代表是什麼身份。

## cookie

- 瀏覽器內部有儲存 cookie 的地方（dev tool -> application -> Cookies）
- 驗證身份後的請求成功後，可以從 request 的 Response Headers 找到 `set-cookie`，之後瀏覽器變會設定 cookie（可以在瀏覽器 console 輸入 `document.cookie` 查看當前 cookie）

實際流程就像是：
1. request 取得 server 回應了，並透過 `set-cookie` 設定 cookie
2. 附上 cookie 的 request 就不是無狀態了，因為 server 可以藉由讀取請求的 cookie 知道其他資訊（比如說登入狀態、購物車資訊等等）

（ref. [白話 Session 與 Cookie：從經營雜貨店開始](https://hulitw.medium.com/session-and-cookie-15e47ed838bc)）

### 會有遇到什麼問題呢？

#### 被人為修改：

因為是存放在瀏覽器內，因此是有機率會被認為竄改。實際大概會是這樣子：

（這樣子 client 就會取得錯誤的資訊）

#### 瀏覽器空間問題

瀏覽器存放空間有限，沒辦法儲存大量資料

## session

> 透過 cookie 傳一組 id，其他資訊就存在 server

1. server 存獨一無二的 ids，並且只傳一組確認身份的 id
2. 瀏覽器收到 response 時再藉由 `set-cookie` 儲存該 id
3. 之後發送請求時帶 cookie 供瀏覽器認人

（ref. [白話 Session 與 Cookie：從經營雜貨店開始](https://hulitw.medium.com/session-and-cookie-15e47ed838bc)）

### 好處是什麼？

#### 不受瀏覽器儲存資料的限制

因為存放的位置從瀏覽器 -> server，所以不會有瀏覽器空間問題

## 為什麼不在前端寫機密邏輯？

因為瀏覽器中可以看到全部前端的程式碼...

## Recap

- http 是無狀態的
- 除了存在瀏覽器，也可以透過網址帶資訊（古早作法）
- session 還是需要透過 cookie 傳遞資訊，只是 session 把資料存在 server 中，所以 cookie 被人為修改也是大丈夫
- 也可以在 request 帶入 token（`headers: { 'Authorization': 'Bearer xxxx' }`）讓 server 知道是誰發出的請求

## 參考資料
1. [白話 Session 與 Cookie：從經營雜貨店開始](https://hulitw.medium.com/session-and-cookie-15e47ed838bc)
2. [前端三十｜27. [WEB] Cookie & Session 是什麼？](https://medium.com/schaoss-blog/%E5%89%8D%E7%AB%AF%E4%B8%89%E5%8D%81-27-web-cookie-session-%E6%98%AF%E4%BB%80%E9%BA%BC-83f9747caf23)