ASP.NET 發布後網址出現亂碼 (S(xxx)) 完整解決方案：Cookieless Session 原理與關閉方法

現象描述

網站部署後，網址列出現類似下列亂碼片段：

https://www.example.com/(S(jnzpixfqi5rge5rnl45vdb45))/Default.aspx

這段 (S(xxxxxxxxx)) 是 Session ID 嵌入 URL 的標誌，而非真正的亂碼。

根本原因：web.config 設定 cookieless="true"

<sessionState mode="InProc" 
              stateConnectionString="tcpip=127.0.0.1:42424" 
              sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" 
              cookieless="true"   <-- 罪魁禍首
              timeout="20" />

原理深度解析

正常模式 (cookieless="false" / "UseCookies")

1. 伺服器建立 Session → 產生 Session ID
2. 透過 Set-Cookie: ASP.NET_SessionId=xxx 寫入瀏覽器 Cookie
3. 後續請求自動攜帶 Cookie → 伺服器識別用戶

Cookieless 模式 (cookieless="true" / "UseUri")

1. 伺服器建立 Session → 產生 Session ID
2. 無法寫入 Cookie (或瀏覽器拒絕 Cookie)
3. ASP.NET 自動將 Session ID 嵌入 URL 路徑：/(S(xxx))/
4. 所有連結、表單動作、重導向自動重寫包含 Session ID
5. 後續請求從 URL 解析 Session ID → 識別用戶

為什麼會預設開啟？

• 早期 ASP.NET 範本/精靈有時預設 cookieless="true" 以支援不接受 Cookie 的舊裝置 (WAP 手機、特定嵌入式瀏覽器)
• 開發者複製舊版 web.config 未注意此設定
• 某些安全性掃描工具建議「不使用 Cookie」導致誤設

解決方案：修改 web.config 關閉 Cookieless

<sessionState mode="InProc" 
              cookieless="false"   <-- 改為 false (或 "UseCookies")
              timeout="20" />

立即生效，無需重新編譯，只需回收應用程式集區或修改 web.config 觸發應用程式重啟。

四種 cookieless 設定值對照

副作用與注意事項

1. 現有使用者 Session 將失效

修改設定後，舊的 URL 嵌入式 Session ID 將無法辨識，使用者需重新登入。建議在維護時段部署。

2. 無 Cookie 環境將無法維持 Session

極少數拒絕 Cookie 的爬蟲、API 客戶端、嵌入式 WebView 將無法維持 Session。若有此需求，需改用 AutoDetect 或實作 Token 型驗證 (JWT)。

3. 安全性考量

• URL 嵌入 Session ID 風險：書籤分享、Referer 洩漏、Proxy 日誌記錄、瀏覽器歷史記錄皆會洩露 Session ID
• Cookie 模式較安全：可設定 HttpOnly、Secure、SameSite 屬性防禦 XSS/CSRF

驗證修正成功

1. 清除瀏覽器 Cookie 與快取
2. 重新造訪網站
3. 確認網址列不再包含 (S(xxx))
4. 開發者工具 Network 標籤確認 Set-Cookie: ASP.NET_SessionId=... 正常送出

總結

網址出現 (S(xxx)) 亂碼，100% 為 cookieless="true" 導致。修改 web.config 設定 cookieless="false" (或 UseCookies) 即可徹底解決。現代 Web 開發應一律使用 Cookie 型 Session，兼具安全性、SEO 友善與使用者體驗。