正常產生驗證用HTTP Cookie卻一直通不過Authorize驗證？

同事詢問一個靈異的狀況。美國同事的電腦，不論如何測試就是無法登入最近採用 ASP.NET Core + Razor Pages 開發的一個新服務網站。此網站使用預設 [Authorize] 來驗證，後端沒有什麼太深的程式碼，就是驗證帳密通過設定驗證 HTTP Cookie。

一開始的方向還在通想會不會是 ASP.NET Core 本身有雷，這個技術還很新，不敢說我們的掌握度還很好，可是想想可能性非常的低，這個 [Authorize] 的發展從 ASP.NET MVC 到 ASP.NET Core 應該算成熟的應用。反覆測試，發現一奇特現像。

• US同事電腦：
  • Chrome 無法登入，一直導回登入頁面。
  • 登入過程需產生的驗證 Cookie ，經 F12 開發工具確認，有正確產生。
• TW同事電腦：
  • Chrome 正常。
  • Firefox 重現無法登入，一直導回登入頁面。

US (Chrome) 與 TW (Firefox) 都有正確產生驗證 Cookie，就是會一直被踢回登入頁面。來後請出 Fiddler 的來查看 HTTP 底層的資訊。

這是登入後寫入驗證 Cookie 的 Reponse Header：

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Kestrel
Set-Cookie: .AspNetCore.Cookies=...HashCode...; path=/HRPM; samesite=lax; httponly

這是正常的能登入 Request Header：

GET http://domain/HRPM HTTP/1.1
Host: domain
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://domain/HRPM/Account/Login?ReturnUrl=%2FHRPM
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,zh-TW;q=0.8,zh;q=0.7
Cookie: .AspNetCore.Cookies=...HashCode...

這是不正常不能登入的 Request Header：

GET http://domain/hrpm HTTP/1.1
Host: domain
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://domain/hrpm/Account/Login?ReturnUrl=%2Fhrpm
Connection: keep-alive
Upgrade-Insecure-Requests: 1

很明顯，不正常的請求根本沒帶 Cookie 過去，當然被擋下導回登入頁。但這是為什麼呢？這很明顯違反正常瀏覽器的行為？

看看 MDN Web docs 的文件：

• HTTP cookies
• Set-Cookie

沒寫哦。哈哈，不然沒事我寫這篇做什麼。

原因，其實我很快就「猜」出來了，問題出在 Cookie 的 Path 的參數，這個 Path 通常都會設定為 Path=/，就 MDN 的文件範例來說path=/docs, "/docs", "/docs/Web/", or "/docs/Web/HTTP" will all be matched。但文件少說了一句：這個 Path 的值大小寫敏感的。也就是說，把有問題請求 URL http://domain/hrpm 換成 http://domain/HRPM 問題立解。

有幾個方向可以解決：

1. 請用戶修正並瀏覽符合 URL
2. 透過前或後端程式幫忙轉換至符合 URL
3. 修正 Path 的設置

不經一事，不長一智。很多 under-table 的知識是碰出來的。