今日目標

明明 cookie、header 都已經處理完了，為什麼還是不能發 issue 呢？今天的目標就是要找出到底是哪個環節出了問題

比較請求

先來觀察平常在 Github 發 issue 的請求長什麼樣子（下圖）：看起來是個 POST 請求，請求中帶著一堆 cookie，Github 處理完之後會用 302 Redirect 讓瀏覽器跳轉到 issue 頁面

在自己架在 localhost 的 Phish Github 發 issue 也是發出 POST 請求、帶了一些 cookie，但卻直接被 Github 422 Unprocessable Entity 打回來QQ

眼尖的你有發現哪裡不一樣嗎（左圖成功、右圖失敗）？右邊發出去的 cookie 好像特別少欸，怎麼會這樣勒

到瀏覽器 Devtool > Application > Storage > Cookies 裡面比較一下到底少了什麼 cookie（左圖成功、右圖失敗）

發現我們自己架在 localhost 的 Phish Github 少了一個叫做 __Host-user_session_same_site 的 cookie

追查 cookie 來源

這個 __Host-user_session_same_site 看名字應該是在登入的時候 Github 該發給我們的號碼牌，來確認一下

？？怪了，Github 明明有發給我號碼牌，但是瀏覽器收到卻沒有存起來

查了一下 MDN Set-Cookie 才發現原來只要是 __Host- 或是 __Secure- 開頭的 cookie 都必須帶有 secure 屬性，而且網站也一定要是 https，簡直就是加強版的 secure 阿

因為我們在 Day13 把 cookie 的 secure 屬性都刪掉了，但 __Host- 開頭的 cookie 又規定一定要有 secure 屬性，所以才會造成有看到 Set-Cookie 但沒有真的存到瀏覽器的情況

因為目前架在 localhost 的網站沒有 HTTPS，所以也沒辦法幫他加上 secure 屬性，那該怎麼辦勒

小結

今天發現了一個大問題：因為 cookie 名稱是 __Host- 開頭所以導致 cookie 沒辦法 set 到瀏覽器，但又沒辦法真的用 HTTPS，所以導致某些功能（發 issue）沒辦法正常使用，雖然這問題不太好處理，但還是有辦法的，大家也可以先想想看該怎麼辦