asp.net 2.0 下的表單驗證Cookieless屬性

asp.net|cookie|表單驗證

剛剛在洗衣服的時候突然想到今天在做WAP程式的表單驗證的時候遇到一個問題,在不支援Cookies的行動裝置模擬器中無法正常進行表單驗證,聯想到昨天使用web.config設定cookieless屬性時會在訪問時會出現"Cannot use a leading .. to exit above the top directory"的異常,自然而然的我就想到了前一段時間困擾我很久的一個網站異常無法使用前置 .. 在頂級目錄上退出(Cannot use a leading .. to exit above the top directory)。綜合一下，終於理解了為什麼會出現這樣的異常，也理解了為什麼在asp.net 2.0 中，將原來cookieless屬性只能設定true|false，改成了可以設定枚舉HttpCookieMode的值,分別為:AutoDetect,UseCookies,UseDeviceProfile,UseUri 。

如果對錶單驗證很有經驗的朋友可能會很清楚，可以有兩種方式來儲存當前的SessionID和使用者的驗證票資訊，分別是使用Cookie和在URL地址加上一串編碼過的字串來標識當前的SessionID和使用者的驗證票資訊。第一種方式非常普遍，對於使用URI來標識當前SessionID和驗證票，我相信如果不是特殊需要的話，相信很多人都會跟我一樣還無法很好理解。我做了兩個簡單的頁面，來類比使用者的驗證過程。當我在web.config中設定cookieless="AutoDetect"時，就跟我們平常一樣，登入的URL是：

http://localhost:1115/FormsAuthentication/Security/Default.aspx

而當我設定cookieless="UseUri"時，這時URL地址就變成了：

http://localhost:1115/FormsAuthentication/(F(V0-gEZNEzXUqevbOqKwNoBcMf6vBWnyNbdpa2UhZzrfOUkGPvyB91-9nFlnBDmCAgdpz4gJ6kq-QOVjbNsvKig2))/Security/Default.aspx

在網站目錄多了一級目錄，這裡的值就是當前會使用者的驗證票資訊和SessionID資訊。在某些場合，這樣做是非常有意義的（或者是必須的），因為在不支援cookie環境下，你要去標識一個是否屬於同一個會話，目前使用者是否已驗證過，等等與會話相關資訊的時候就會變得異常的困難。

瞭解了這兩個儲存會話資訊的方式後,我們再來討論一下,asp.net team為什麼把原來只能設定true | false的屬性改成可以設定不同的枚舉值.首先我們來看看這4個值的含意(在Windows Live Writer 不能畫表格 :< ):

AutoDetect:自動檢測用戶端實際是否支援cookie再來決定使用兩種方式中的哪一種(最佳適應)。

UseCookies:不管用戶端是否支援cookie,反正都使用cookie來標識(第一種方式)。

UseDeviceProfile:根據裝置檔案來判斷是否支援cookie,進而決定使用哪種方式。相信很多人都對這個概念很模糊，由於最近在研究WAP，所以對它有一些簡單的認識。在<%windir%>Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers目錄下有很多的.browser檔案，這些檔案就是用來標識對應的裝置（瀏覽器）的瀏覽能力（描述不是很清楚，就是一些技術參數，是否支援cookie and so on），在asp.net中，會根據這些.browser檔案，動態產生從HttpBrowserCapabilities繼承下來的裝置參數類型，標識對應的裝置的一些參數值，編程中可以通過Request.Browser得到這個裝置參數對象，並使用。

UseUri :與UseCookies類似的，不管用戶端是否支援cookie，反正都使用第二種方式。

特別說明：為什麼特彆強調“實際”，和詳細描述UseDeviceProfile呢？主要是因為，我發現由於可能是裝置檔案中標識的參數與對應的裝置的實際並不完全符合，（比如，有可能裝置檔案中標識這種裝置支援cookie，但實際的裝置卻不支援）。所以如果要根據裝置的實際來選擇是否使用cookie，那就要使用AutoDetect值了。裝置檔案只能是做為參考，當然如果你對裝置檔案有充分控制條件的話那就另當別論了。而且還有一點要特別注意，AutoDetect並不是預設值，UseDeviceProfile才是。

回到正題，為什麼要改cookieless屬性的可選值呢？毫無疑問，是為了增加程式的可操控性。原來的值有點太過單一化了，二選一，沒有商量的餘地。現在我們可以根據各種不同的情況來讓程式動態或程式員手動選擇。結合這一段時間的WAP開發經驗，我想這樣做的一個目的就是為了能更好的相容行動裝置，相容WAP的應用。目前還有很多的裝置還並不支援cookie。

有了上面的介紹後，我還想來解開為什麼會出現“Cannot use a leading .. to exit above the top directory”異常的迷團。前幾天也有收到一個朋友的來信，也是在使用CommunityServer 2.0遇到這個問題，(相信目前遇到最多的就是asp.net 2.0版的CommunityServer了)。目前使用了Url Rewrite，所以我們程式的很多URL都是假的，所以如果在頁面中使用了相對路徑（~/）的話，那我們就有可能遇到這樣的麻煩了。因為搜尋引擎（特別是google）不支援cookie，所以在它訪問網站的時候就會使用上面提到的第二種方式來標識會話資訊，這時候URI就多了一級了，所以在這個頁面下所有的連結地址都是多一個../，無法正常訪問了，從而造成上面這個異常的出現。(其實可以看出這個異常本身與Url Rewrite並沒有多大關係，只不是communityserver和我的程式中都使用了url rewrite)。

解決辦法有三種：

1.設定cookieless = UseCookies，不管用戶端是否支援cookie都使用cookie。

2.因為預設cookieless = UseDeviceProfile，所以可以為搜尋引擎建立一個裝置檔案.browser，弄虛作假一下。《Get GoogleBot to crash your .NET 2.0 site》就有給出了這樣的做法了。

3.修改程式，將裡面的相對路徑（~/）改成絕對路徑表示（可以使用Resolve方法）。

到目前為止對cookieless的討論就算告一段落了，我發現到目前為止中文社區好像還沒有很多人對這一屬性有過深入的討論。文中很多都是我個人綜合理解，總結出來，裡面可能會有很多錯誤的認識和觀點，歡迎大家給我指正和補充。