ASP.NET中的cookieless屬性
WAP程序的表單驗(yàn)證的時(shí)候遇到一個(gè)問題,在不支持Cookies的移動(dòng)設(shè)備模擬器中無法正常進(jìn)行表單驗(yàn)證,聯(lián)想到昨天使用web.config設(shè)置cookieless屬性時(shí)會(huì)在訪問時(shí)會(huì)出現(xiàn)"Cannot use a leading .. to exit above the top directory"的異常,自然而然的我就想到了前一段時(shí)間困擾我很久的一個(gè)站點(diǎn)異常無法使用前導(dǎo) .. 在***目錄上退出(Cannot use a leading .. to exit above the top directory)。綜合一下，終于理解了為什么會(huì)出現(xiàn)這樣的異常，也理解了為什么在ASP.NET 2.0 中，將原來cookieless屬性只能設(shè)置true|false，改成了可以設(shè)置枚舉HttpCookieMode的值,分別為:AutoDetect,UseCookies,UseDeviceProfile,UseUri 。
如果對(duì)表單驗(yàn)證很有經(jīng)驗(yàn)的朋友可能會(huì)很清楚，可以有兩種方式來保存當(dāng)前的SessionID和用戶的驗(yàn)證票信息，分別是使用Cookie和在URL 地址加上一串編碼過的字符串來標(biāo)識(shí)當(dāng)前的SessionID和用戶的驗(yàn)證票信息。***種方式非常普遍，對(duì)于使用URI來標(biāo)識(shí)當(dāng)前SessionID和驗(yàn)證票，我相信如果不是特殊需要的話，相信很多人都會(huì)跟我一樣還無法很好理解。我做了兩個(gè)簡(jiǎn)單的頁(yè)面，來模擬用戶的驗(yàn)證過程。當(dāng)我在web.config中設(shè)置cookieless="AutoDetect"時(shí)，就跟我們平常一樣，登錄的URL是：
http://localhost:1115/FormsAuthentication/Security/Default.aspx
而當(dāng)我設(shè)置cookieless="UseUri"時(shí)，這時(shí)URL地址就變成了：
http://localhost:1115/FormsAuthentication/(F(V0-gEZNEzXUqevbOqKwNoBcMf6vBWnyNbdpa2UhZzrfOUkGPvyB91-9nFlnBDmCAgdpz4gJ6kq-QOVjbNsvKig2))/Security/Default.aspx
在站點(diǎn)目錄多了一級(jí)目錄，這里的值就是當(dāng)前會(huì)用戶的驗(yàn)證票信息和SessionID信息。在某些場(chǎng)合，這樣做是非常有意義的（或者是必須的），因?yàn)樵诓恢С謈ookie環(huán)境下，你要去標(biāo)識(shí)一個(gè)是否屬于同一個(gè)會(huì)話，當(dāng)前用戶是否已驗(yàn)證過，等等與會(huì)話相關(guān)信息的時(shí)候就會(huì)變得異常的困難。
了解了這兩個(gè)保存會(huì)話信息的方式后,我們?cè)賮碛懻撘幌?ASP.NET team為什么把原來只能設(shè)置true | false的屬性改成可以設(shè)置不同的枚舉值.首先我們來看看這4個(gè)值的含意(在Windows Live Writer 不能畫表格 :< ):
AutoDetect:自動(dòng)檢測(cè)客戶端實(shí)際是否支持cookie再來決定使用兩種方式中的哪一種(***適應(yīng))。
UseCookies:不管客戶端是否支持cookie,反正都使用cookie來標(biāo)識(shí)(***種方式)。
UseDeviceProfile:根據(jù)設(shè)備文件來判斷是否支持cookie,進(jìn)而決定使用哪種方式。相信很多人都對(duì)這個(gè)概念很模糊，由于最近在研究WAP，所以對(duì)它有一些簡(jiǎn)單的認(rèn)識(shí)。在<%windir%>Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers目錄下有很多的.browser文件，這些文件就是用來標(biāo)識(shí)對(duì)應(yīng)的設(shè)備（瀏覽器）的瀏覽能力（描述不是很清楚，就是一些技術(shù)參數(shù)，是否支持cookie and so on），在ASP.NET中，會(huì)根據(jù)這些.browser文件，動(dòng)態(tài)生成從HttpBrowserCapabilities繼承下來的設(shè)備參數(shù)類型，標(biāo)識(shí)對(duì)應(yīng)的設(shè)備的一些參數(shù)值，編程中可以通過Request.Browser得到這個(gè)設(shè)備參數(shù)對(duì)象，并使用。
UseUri :與UseCookies類似的，不管客戶端是否支持cookie，反正都使用第二種方式。
特別說明：為什么特別強(qiáng)調(diào)“實(shí)際”，和詳細(xì)描述UseDeviceProfile呢？主要是因?yàn)椋野l(fā)現(xiàn)由于可能是設(shè)備文件中標(biāo)識(shí)的參數(shù)與對(duì)應(yīng)的設(shè)備的實(shí)際并不完全匹配，（比如，有可能設(shè)備文件中標(biāo)識(shí)這種設(shè)備支持cookie，但實(shí)際的設(shè)備卻不支持）。所以如果要根據(jù)設(shè)備的實(shí)際來選擇是否使用cookie，那就要使用AutoDetect值了。設(shè)備文件只能是做為參考，當(dāng)然如果你對(duì)設(shè)備文件有充分控制條件的話那就另當(dāng)別論了。而且還有一點(diǎn)要特別注意，AutoDetect并不是默認(rèn)值，UseDeviceProfile才是。
回到正題，為什么要改cookieless屬性的可選值呢？毫無疑問，是為了增加程序的可操控性。原來的值有點(diǎn)太過單一化了，二選一，沒有商量的余地。現(xiàn)在我們可以根據(jù)各種不同的情況來讓程序動(dòng)態(tài)或程序員手動(dòng)選擇。結(jié)合這一段時(shí)間的WAP開發(fā)經(jīng)驗(yàn)，我想這樣做的一個(gè)目的就是為了能更好的兼容移動(dòng)設(shè)備，兼容WAP的應(yīng)用。目前還有很多的設(shè)備還并不支持 cookie。
有了上面的介紹后，我還想來解開為什么會(huì)出現(xiàn)“Cannot use a leading .. to exit above the top directory”異常的迷團(tuán)。前幾天也有收到一個(gè)朋友的來信，也是在使用CommunityServer 2.0遇到這個(gè)問題，(相信目前遇到最多的就是ASP.NET 2.0版的CommunityServer了)。目前使用了Url Rewrite，所以我們程序的很多URL都是假的，所以如果在頁(yè)面中使用了相對(duì)路徑（~/）的話，那我們就有可能遇到這樣的麻煩了。因?yàn)樗阉饕妫ㄌ貏e是google）不支持cookie，所以在它訪問站點(diǎn)的時(shí)候就會(huì)使用上面提到的第二種方式來標(biāo)識(shí)會(huì)話信息，這時(shí)候URI就多了一級(jí)了，所以在這個(gè)頁(yè)面下所有的鏈接地址都是多一個(gè)../，無法正常訪問了，從而造成上面這個(gè)異常的出現(xiàn)。(其實(shí)可以看出這個(gè)異常本身與Url Rewrite并沒有多大關(guān)系，只不是communityserver和我的程序中都使用了url rewrite)。
解決辦法有三種：
1.設(shè)置cookieless = UseCookies，不管客戶端是否支持cookie都使用cookie。
2.因?yàn)槟J(rèn)cookieless = UseDeviceProfile，所以可以為搜索引擎建立一個(gè)設(shè)備文件.browser，弄虛作假一下。《Get GoogleBot to crash your .NET 2.0 site》就有給出了這樣的做法了。
3.修改程序，將里面的相對(duì)路徑（~/）改成絕對(duì)路徑表示（可以使用Resolve方法）。
到目前為止對(duì)cookieless的討論就算告一段落了，我發(fā)現(xiàn)到目前為止中文社區(qū)好像還沒有很多人對(duì)這一屬性有過深入的討論。文中很多都是我個(gè)人綜合理解，總結(jié)出來，里面可能會(huì)有很多錯(cuò)誤的認(rèn)識(shí)和觀點(diǎn)，歡迎大家給我指正和補(bǔ)充。
【編輯推薦】
