大匠之風: Delphi WebBroker ISAPI Cookie Debugging: Resolving Client-Side Access Issues (CHT)

2018/05/24

Delphi WebBroker ISAPI Cookie Debugging: Resolving Client-Side Access Issues (CHT)

Cookie 在網頁開發幾乎是必須，而它有幾個限制：

容量為 4 KB
明碼傳遞
會強制放在 Request / Response 一起傳送，增加傳輸流量

增加 4 KB 的傳輸流量在現在這個動不動就幾個 Mbit 的網路速度來說，離負載也差得太遠。

Https 也快要成為主流，所以明碼傳遞也不是問題。

最近的問事中，有一項是開發 WebBroker 專案中，在 Cookie 設計上遇到些麻煩：

Exe / Debug Server 模式下，Cookie 在 Server 及 Client 皆可正確存取。
ISAPI 模式下，Server 可以存取由 Server 建構的 Cookie，但 Client 找不到，反之亦然。

Delphi 3 以來，從沒見過有人提出這類問題。

只好開啟抓鬼模式了。

WebBroker Cookie 的基本原理

首先，要做的是 -- 先了解所有的後端技術 (包含 WebBroker) 是如何建立 Cookie 的：

Set-Cookie: name=value; expires=date; path=path; domain=domain; secure

網路上所有的文件只會說 name, expires 的設定法，而 path 和 domain 則由後端技術在背景處理。

當然，要指定也不是問題，在 Response header 自己寫入也可以，只是這是找自己麻煩的行為，沒必要多此一舉。

WebBroker 在 Exe/Debug Server 與 ISAPI 模式下的 Cookie 差異

不過，在這個案例中，Server / Client 彼此送的 Request / Response 似乎不太一樣，看來關鍵就在這兩個身上。

經過開啟 Cookie 檔案研究一番後，才真相大白，原來真是 Path 不同在搞鬼。

在 Exe / Debug Server 時，僅僅只是在 Localhost 下操作，所以 Domain 和 Path 分別是：

Domain = Localhost
Path = /

所以一切正常，Server / Client 溝通順利。

ISAPI 模式下的 Cookie 路徑問題

到了 ISAPI 時，如下圖所示：

【myCoo】是 Server side 的 ISAPI 建立的。
【XX】是 Client side 的 HTML 建立的。

彼此間認不出來是很正常的，因為它們的 Path 屬性不同！

解決 ISAPI Cookie 的客戶端存取問題

經過開啟 Cookie 檔案研究一番後，才真相大白，原來真是 Path 不同在搞鬼。

本次超自然現象終於順利解決，真是很厲害的欺敵戰術呢！

要解決這個問題，關鍵在於確保 Server 端和 Client 端產生的 Cookie 具有相同的 Path。在 WebBroker 中，你可以在建立 Cookie 時明確指定 Path 屬性。

procedure TWebModule1.WebModule1WebActionItem1Action(Sender: TObject;
  Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
var
  MyCookie: TCookie;
begin
  MyCookie := TCookie.Create('MyCookie', 'CookieValue');
  MyCookie.Path := '/'; // 設定 Path 為根目錄
  Response.Cookies.Add(MyCookie);
  Response.Content := 'Cookie set!';
end;

跨域資源共用 (CORS) 的考量

如果您的 WebBroker 應用程式涉及到跨域請求 (Cross-Origin Requests)，除了 Cookie 的 Path 設定外，還需要考慮 CORS (Cross-Origin Resource Sharing) 的設定。

總結

透過了解 WebBroker 在 Exe, ISAPI 的差異，可以更有效的處理 cookie 問題。

而我又再往前向【DSP.NET】邁進一大步了！ (誤)

大匠之風

網頁