利用session,cookie進行安全性控制

Sessions的介紹

什麼是Sessions?session其實指的就是訪問者從到達某個特定主頁到離開爲止的那段時間，每個訪問者都會單獨獲得一個session。

Sessions

可以用來儲存訪問者的一些喜好，例如：訪問者是喜好綠色背景還是蘭色？訪問者是否對分屏方式懷有敵意。以及訪問者是否寧可瀏覽純文本的站點，這些信息可以依據sessions來跟蹤。

Sessions

還可以創建虛擬購物籃。無論什麼時候用戶在你的網站中選擇了一種產品，那麼這種產品就會進入購物籃，當他或她準備離開時，就可以立即進行以上所有選擇的產品的訂購。這些購物信息可以被保存在Session中。

Sessions的使用和處理

Session

的發明是填補HTTP協議的侷限，請注意HTTP協議是怎樣工作的－用戶發出請求，服務端作出響應，這種用戶端和服務端之間的聯繫就是離散的，非連續的。

在HTTP協議中沒有什麼能夠允許服務端來跟蹤用戶請求。在服務端完成響應用戶請求後，服務端不能持續與該瀏覽器保持連接。從網站的觀點上看，每一個新的請求都是單獨存在的，因此，HTTP協議被認爲是stateless協議，在用戶在多個主頁間轉換時，你就根本無法知道他的身份。

Sessions

注意

的引用就是彌補了這個缺陷。利用Sessions，你就可以在一個用戶在多個主頁間切換的時候也能保存他的信息。這樣很多以前根本無法去做的事情變得簡單多了。

現在還有很多瀏覽器不能支持Cookies，如果想要具體瞭解這些，看後面的相關部分。

開始Session信息

Active Server Pages

的Sessions非常好用，你能夠利用Session對象來對session全面控制，如果你需要在一個用戶session中存儲信息，你只需要簡單的直接調用Session對象就可以了，下面是個例子：

<HTML>

<HEAD><TITLE>Session

<BODY>

Session(

示例</TITLE></HEAD>“Greeting”)=“歡迎!”

Response.Write(Session(

</BODY>

</HTML>

“Greeting”))當Active Server Page執行時，瀏覽器上顯示出”歡迎!”的字段，腳本第一行是給Greeting賦值爲”歡迎!”，第二行將這個字段顯示出來。

<HTML>

<%=Session(

</Body>

</html>

不過，這種操作沒什麼大不了的，但是，可以假象一個同樣的用戶進入另一個主頁，例如，下面這個Active Server Pages:另一頁</TITLE></HEAD>“Greeting”)%>當他進入這頁，同樣的”歡迎!”又顯示出來了，注意這一頁沒有賦值操作，這個Greeting變量的值是前面那頁賦值的。

你無法用普通的腳本變量來進行這種處理，因爲一般的變量只在一個單獨主頁內有效，而Session變量在用戶離開網站前一直存在生效。

要理解的很重要的一點是Session變量是針對特定用戶相聯繫的。針對某一個用戶賦值的Session變量是和其他用戶的Session變量完全獨立的，不會存在相互影響。換句話說，這裏面針對每一個用戶保存的信息是每一個用戶自己獨享的，不會產生公享情況。例如下面這個例子(針對於註冊表的例子)：

Session(

Session的內容

幾乎所有的Session存儲的內容存在Content集合中。例如，下面兩個語句是等效的：

<% Session(

<% Session.Contents(

“MyVar”)=“Some data” %>“MyVar”)=“Some data” %>正如前面對集合的討論中說道的，你仍然可以利用Count屬性來檢查集合的數量。同樣你也可以利用FOR EACH，FOR ...NEXT循環來顯示Content所有內容。下面的例子使用了這些方法：

Session(

“Username”)=“謝建雲”

Session(

“Usercompany”)=“邁至科網絡”

這裏面

Session對象的Content集合一共有<%=Session.Content.Count%>項。

<hr>

FOR EACH thing IN Contents

Response.Write(

<hr>

FOR I=1 to Session.Contents.Count

Response.Write(

“<br>“&thing&Session.Contents(thing))“<br>“&Session.Contents(i))

在這個腳本中，創建了兩個

Session結束的控制

服務器怎麼知道一個Session結束了呢？換句話說，怎樣知道是否已經離開了這個站點而去了另一個站點或者已經關掉電腦看電影去了呢。如果一個人一直沒有提出請求或者刷新主頁長達20分鐘，那麼服務器就默認爲用戶已經離開了。這種策略就使得服務端可以釋放對用戶進程進行跟蹤時使用的資源。

對於有些網絡站點，20分鐘顯然有些短，例如，對於高水平選手進行的網絡圍棋，很多步子是要長考的。那麼這時候20分鐘如果釋放了資源，這個棋手就可能被服務端轟出局，這就不爽了。

有些網絡站點則相反，資源有限而訪問量又很大，沒有什麼需要耗費時間的信息傳遞，那麼白白浪費資源是很可惜的，也會使其他訪問者的訪問速度受到影響。

不過，對於Active Server Pages來說，對這些進行控制都沒什麼難度，Session對象有這種Timeout屬性，你完全可以限定一個Session存在的限定時間。例如：下面這個腳本將限制時間設爲60分鐘：

<% Session.Timeout=60 %>

注意

你也可以利用Internet Service Manager來進行這種控制。從Application設置對話框中，點擊Active Server Pages表並且限定Session的限制時間。

當用戶的Session時間過期後，如果用戶刷新了主頁，那麼將被認爲是新的訪問者，所有以前的Session信息會全部失去。你也可以利用Abandon方法來消除一個Session。這裏再引入一個SessionID屬性，這將自動分別爲每一個Sessioin分配不同的編號。

<HTML>

<HEAD><TITLE>Abandon Session</TITLE></HEAD>

<BODY>

<BR>

<% Session.Abandon %>

<BR>

</BODY>

</HTML>

Sessions事件

和其他對象不同的是，Session對象中有事件（Event）。一共兩種：Session_OnStart事件，當一個Session開始時被觸發。還有Session_OnEnd事件，當一個Session結束時被觸發。在一個腳本中你可以和其中一個並且只能和其中一個事件關聯。

在事件觸發時下面這些腳本的語句被執行。這兩個腳本位於特定的文件Global.asa。這個文件位於你的網站應用的根目錄。它包括了一些通用程序段和你的網站應用。Global.asa文件有如下結構：

SUB Application_OnStart

END SUB

</SCRIPT>

SUB Application_OnEnd

END SUB

</SCRIPT>

SUB Session_OnStart

END SUB

</SCRIPT>

SUB Session_OnEnd

END SUB

</SCRIPT>

注意

下一章提供更加詳細的關於Global.asa文件的內容

Global.asa

包括四個腳本。這裏面有一個是根據Session_OnStart觸發，另一個是根據Session_OnEnd觸發（下一章介紹剩下的另外兩個腳本）

請注意Global.asa使用了微軟的HTML拓展<SCRIPT>標記語法來限制腳本，這也就是說，你必須用<SCRIPT>標記來引用這兩個事件而不能用<%和%>符號引用。例子中Global.asa使用的是VBScript，但是你也可以使用其他腳本語言。

在Global.asa中不能有任何輸出語句，無論是HTML的語法還是Response.Write()方法都是不行的，Global.asa是任何情況下也不能進行顯示的。

你只需要在Global.asa中添加一些你希望執行的腳本，那麼只要Session一創建，這些腳本就會自動執行，例如下例：

SUB Session_OnStart

Session(

“Username”)=“Unknow”

Session(

“Userpassword”)=“Unknow”

END SUB

</SCRIPT>

這個腳本將”Unkonw”值賦給了Username和UserPassword變量。這個例子將在任何一個Session 創建的時候就執行。

Session_Onstart

腳本可以用於很多種目的。例如，你希望訪問者必須瀏覽某一個主頁，下面的例子就在用戶進程開始時進行了這種引導，那麼這裏面使用Response.redirect方法。下面是這個例子：

SUB Session_OnStart

MyHomepage=

“/homepage.asp”

RequestPage=Request.ServerVariables(

IF NOT (STRCOMP(MyHomePage,RequestPage,vbTextCompare)=0) THEN

Response.Redirect MyHomePage

END IF

END SUB

</SCRIPT>

“SCRIPT_NAME”)在這個腳本中，用戶請求和主頁路徑進行比較，如果不是一樣的，用戶就被自動引導到該主頁。

下面的例子將Session_OnStart和Session_OnEnd都進行了使用：

SUB Session_OnStart

Response.AppendToLog Session.SessionID&

” Starting”

END SUB

</SCRIPT>

SUB Session_Onend

Response.AppendToLog Session.SessionID&

” Ending”

END SUB

</SCRIPT>

Session是怎樣工作的？

Session

其實是利用Cookie進行信息處理的，（參見後面有關Cookies的介紹），當用戶首先進行了請求後，服務端就在用戶瀏覽器上創建了一個Cookie，當這個Session結束時，其實就是意味着這個Cookie就過期了。

注意

爲這個用戶創建的Cookie的名稱是ASPSESSIONID。這個Cookie的唯一目的就是爲每一個用戶提供不同的身份認證。如果你對名字是ASPSESSIONID的COOKIE感到好奇，你可以利用ServerVariables集合的COOKIE Header來接受這個信息，參看下面這個腳本：

<%=Request.ServerVariables(

Session變量自己不會存在用戶瀏覽器上。不過，ASPSESSIONID這個cookie需要使用session變量。server使用ASPSESSIONID cookie來將特定的用戶和特定的session信息聯繫起來。沒有cookie的話，Server就不會瞭解到每一個特定用戶在網站中移動的信息。

注意

利用SessionID變量存儲ASPSESSIONID cookie和直接對名爲ASPSESSIONID的cookie賦值有很大不同。微軟利用了一個複雜的數學算法對SessionID進行了加密措施，以防止黑客猜測出SessionID的值並且依據這個獲得不該獲得的身份或權限。

你可以用兩種方法屏蔽掉SessionID，一種是將全站進行屏蔽，另外一種是將一個單獨Active Server Page進行相應屏蔽。

如果想要將整個站點的Session操作進行屏蔽，你可以使用Internet Service Manager。從Application設置對話框，點擊Active Server Pages表並且取消對Enable Session State選項的選擇。

你還可以在特定的Active Server Page的首行加入使之屏蔽的語句來進行這種操作。

<% EnableSessionState=False %>

由於

Session對象使用了Cookies，那麼它的兼容性就受到了限制，一些老的瀏覽器顯然是不行的，新的瀏覽器象是NetScape4.0也提供了屏蔽Cookie的選項。

注意

這樣就出了問題、由於Cookie不能適用於所有瀏覽器，那麼在建站時你就必須注意了，如果你的網站定位於大衆通用，就必須考慮各種不同的用戶情況。不過現在確實有可以替代的方法，有些取代Cookies來進行身份認證的方法將在後面的章節中進行討論。

很少有網絡技術能夠象cookies來在網絡用戶間製造這樣大的爭論。Cookies只是一個無辜的名字，但是許多用戶將這與邪惡的目的連在一起。

Netscape

首先在它的瀏覽器中引入了cookies，從那時起，World Wide Web協會就支持cookie標準。大部分瀏覽器現在都兼容cookie的使用。

目前有些

是什麼？瀏覽器用一個或多個限定的文件支持Cookie。這些文件在Windows機器上叫做Cookie文件或者在Macintosh中叫做magic cookie文件，被網站用來在上面存儲Cookie數據。網站可以在這些Cookie文件中插入信息。這樣對有些網絡用戶就有些副作用。有些用戶認爲這造成了對隱私的侵犯。更糟的是：有些人認爲Cookie是對個人空間的侵佔。Cookie是臨時的，還有一些則是持續的。例如，cookies被Active Sever Pages用來跟蹤用戶進程直到用戶離開網站。另外有些Cookie則保持在Cookie文件中直到用戶返回時又進行調用。

在cookie文件中保存cookies會產生很大的問題。主要是有些用戶擔心會跟蹤用戶網上衝浪的習慣。害怕這種信息如果落入一些‘黑手’，那麼個人也就可能成爲一大堆廣告垃圾信箋的對象，不過，這種擔心根本不會發生，因爲無法跨過網站來獲得cookie信息，以這種目的來應用Cookie是不可能的。不過，由於一些用戶錯誤的理解以及‘以訛傳訛’，一些瀏覽器開發商別無選擇只能作出響應（例如Netscape4.0提供了屏蔽Cookie的選項）。

注意

目前一些有關Cookie侵犯隱私權的討論已經到了歇斯底里的地步，甚至包括網站站長、專家級的一些人物也在這種認識上犯過錯誤。

更過分的是，很多技巧的技術甚至已經可以在不能屏蔽

目前的主流瀏覽器是這樣的，IE和NETSCAPE都提供了附加的控制Cookie的手段，其中NETSCAPE4.0不但可以對接受Cookie進行警告，而且還可以屏蔽掉Cookie, IE3.0也可以屏蔽Cookie，但是由於微軟開發出了Active Server Pages，因此在IE4.0中就只能進行接受警告而沒有提供屏蔽選項。cookie的瀏覽器上進行Cookie的屏蔽。例如，將你的cookie文件作成只讀（參見http://www.cookiecentral.com）

很不幸，由於上述原因，你的網站利用Cookie就會有各種麻煩，甚至造成Session的調用失敗。

Cookie

是怎樣工作的

將通過HTTP Headers來從服務端返回到瀏覽器上。服務端首先在響應中利用Set-Cookie header來創建一個Cookie，瀏覽器後面的請求的cookie header中就會返回這個Cookie來完成瀏覽器的認證。

Set-Cookie: UserName=BILL+Gates;path=/;domain=aspsite.com;

expires=Tuesday,01-Jan-99 00:00:01 GMT

假設你創建了一個名字爲UserName的Cookie來包含訪問者的信息，創建Cookie時，Server的Header就象下面（假設訪問者爲Bill Gates）:這個Header就在瀏覽器的電腦上的Cookie文件中添加了一條記錄。瀏覽器將名字爲UserName的Cookie賦值爲Bill Gates。請注意這個cookie的值是進行了URL-encoded操作的。

後來，header通知瀏覽器將cookie通過請求以忽略路徑的方式返回服務端，因此，一個Cookie設定後，其應用的所有文件就必須在同一個目錄下，例如如果開始指定的路徑是/private目錄，那麼cookie Header對文件：/private/mypage.asp的請求就可以，而/mypage.asp由於路徑變動就無法利用這個Cookie了。

domain

注意

屬性能夠在瀏覽器端更加對cookie發送進行限定。在這個例子中，cookie只能傳到指定的服務器上，而決不會跑到什麼www.yahoo.com或者什麼其他網站。

現在的瀏覽器在判斷Cookie的路徑時是區分大小寫的，這就意味着如果路徑是/private，那麼以/PRIVATE路徑方式就無法進行這個Cookie的調用和認證。

最後，Expires標記限定了Cookies的過期時間，在例子中的Header中，限定瀏覽器將該Cookie保存到1999年1月1日第一秒，實際上，瀏覽器在接受的Cookie很多時，還會自動進行刪除。

瀏覽器創建了一個Cookie後，在每一個針對該網站的請求時就都會在Header中帶着這個Cookie，也就是每一次滿足該路徑的情況下這個Cookie都會有效。不過，對於其他網站的請求Cookie是絕對不會跟着發送的。瀏覽器會這樣一直髮送到Cookies過期爲止。Cookie Header如下：

cookie: username: Bill+Gates

在Active Server Pages中創建和讀取Cookies

當利用Active Server Pages創建了一個cookie之後，你就可以使用Response對象的Cookie集合了。你可以創建兩種cookie；一種是單值的，另一種可以認爲是cookie字典類型，即允許多個鍵值對的存在。

創建單值的相對簡單，如下腳本：

<% Response.Cookies(

“Username”)=”Bill Gates”

Response.Cookies(

“Username”).Expires=”Jan 1,1999”

這個腳本的工作一目瞭然，將名字爲Username的Cookie賦值爲Bill Gates，同時將過期時間限定爲1999年1月1日，這裏面需要說明的是，Expires屬性如果不進行賦值，那麼默認的就是用戶一離開網站就過期。

前面的腳本是創建一個

由於這個例子腳本創建的是Header的部分，那麼你就必須在你的Active Server Pages的任何輸出語句之前進行這個腳本的操作，或者使用Buffer輸出，（參看14章的有關小節）。Cookie的簡單示例，只是使用了最常用的Expires屬性，其實還有許多其他屬性也可以自行設置，下面是一個比較完全的例子：

Response.Cookies(

“Username”)=”Steve Jobs”

Response.Cookies(

“Username”).Expires=”Jan 1, 1999”

Response.Cookies(

“Username”).Path=”/examples”

Response.Cookies(

“Username”).Domain=”aspsite.com”

Response.Cookies(

■

■最後是

“Username”).Secure=True這個腳本例子和前面的其實沒有什麼區別，不過有三個附加的屬性需要解釋：Path屬性是用來更加嚴格的限定瀏覽器發送Cookie，在這個例子中，只有針對於 /examples目錄的請求的Header中才攜帶Cookie信息，例如/examples/hello.asp以及 /examples/chapter16/hello.asp的請求都會在Header上攜帶Cookie信息，但是如果是瀏覽器對/hello.asp的請求就不會攜帶該Cookie信息。Path屬性的默認值是該Cookie創建的Active Server Pages所在的路徑。（也就是說，即便不做指定，也不會跨過目錄發送Cookie）Domain屬性，限定了Cookie發送的網站，例子中的aspsite.com說明cookie可以被髮送到www.aspsite.com或者beetle.aspsite.com或者yeah.aspsite.com等等，同樣作爲默認值是該Cookie創建的網站。Secure屬性，顧名思義，該屬性設爲True則傳遞中就實行了加密算法，如果你正在使用安全接口層，那麼你就可以使用這個屬性（參見第二章，安裝使用 Internet Information Server）

在一個Active Server Page中讀取cookie，你只需要使用Request對象的Cookies集合，例如，輸出一個cookie值，那麼腳本如下：

<%=Request.Cookies(

“Username”) %>這個腳本將名字爲Username的Cookie值進行了輸出，和以前同樣的是，你依然可以利用For Each循環或者利用Count屬性和For …Next循環結合的方式來將Cookie集合的所有屬性值顯示出來，下面這個例子的運行結果應當無須解釋了。

For EACH thing IN Request.Cookies

Response.write(

“<BR>”&thing&Request.Cookies(thing))

創建多個Cookie

你當然還可以創建不止一個Cookie,只是在Response對象的Cookies集合中簡單的定義多個名稱就可以了。不過，許多瀏覽器對一個指定網站就限定了三到四個Cookie。

創建多個Cookie還有一種選擇，就是創建一個Cookie字典，那麼一個Cookie字典中就可以含有多個鍵值對，下面是這麼一個字典的例子：

Response.Cookies(

“User”)(“Name”)=”Bill Gates”

Response.Cookies(

“User”)(“Password”)=”billions”

這個腳本創建了一個名爲User的Cookie字典，其中含有兩個鍵分別是Name和 Password，當這麼Cookie字典創建時，請求的Header中是這樣的信息：

Set-Cookie:User=Name=Bill+Gates&Password=billions

一個名字爲User的Cookie創建了，其中含有兩個鍵值對，這意味着所有的鍵和相應的值都在一個大的Cookie中。

接受這樣的Cookie值，你還可以利用以前的Response對象的Cookies集合，既可以將其全部顯示，(這樣顯示就是沒有經過解碼的Header中的源代碼，也就是上面Header中的信息，這樣一般都是用於調試工作）也可以按每一個鍵的相應名稱顯示相應值，如下例，無須解釋結果：

<%=Request.Cookies(

“User”) %>“User”)(“Name”)%>“User”)(”Name”)%>

注意

利用Cookie技術傳遞諸如密碼這樣的信息要特別小心，因爲一般說來，這種信息是未經加密的，當然，如果你的網站有安全接口層技術，也可以進行加密傳輸，但是在瀏覽器端該信息還是存放在文本文件中。

如果希望知道一個Cookie是否是一個Cookie字典，可以用HasKeys屬性，例如下面腳本如果返回值爲True，那麼就是一個Cookie字典。

<%=Request.Cookies(

不利用Cookie來保持信息

其實這部分也是老調重彈，前面章節已經介紹過

QueryString字段的使用及接收，以及Form的接收，其實這兩種手段也可以進行一些信息保存，最後我們會對這三種方案進行綜合比較。

利用QueryString來保持信息

第15章中有關小節有所介紹，由於你可以在連接中添加任何QueryString字段，那麼，只要你在網站的所有連接中添加一個保存用戶某種信息的字段，再在各個程序上進行相應處理，就可以進行模擬的跟蹤，如下例：

<HTML>

<HEAD><TITLE>Query

<BODY>

Username=Server.URLEncode(

<A Href=

</BODY>

</HTML>

字段進行信息保留</TITLE></HEAD>“Bill Gates”)”/nextpage.asp?<%=UserName%>”>點擊這裏</a>這個腳本將Bill Gates賦值給Username的變量，然後將它通過QueryString傳遞給nextpage.asp，那麼在Nextpage.asp中你就可以接受然後繼續進行這個參數的傳遞。例如：下面就是Nextpage.asp的一個示例：

<HTML>

<BODY>

Username=Server.URLEncode(

<A HREF=

</body>

</html>

“Request.QueryString(“Username”))”/thirdpage.asp?<%=Username%>”>點擊這裏</a>這個優點是顯然適用於任何瀏覽器，但是必須承認，這樣傳遞來保存信息實在太麻煩了，所有的連接都要考慮到，每一個Active Server Pages都必須相應處理一下，而且用戶很可能‘一不小心’就溜出了這種跟蹤之外。修改起來也過於麻煩。

另一個缺點是針對不同的瀏覽器必須考慮長度限制，前面章節介紹過這種限制，現在有的瀏覽器對於過長是截取信息，有的則乾脆報錯，不過相信這都不是你所希望的。同時安全性沒有保證。

利用Form的hidden類型進行信息傳遞

如果你確實需要傳遞大量信息而又不想選用Session變量，那麼您別無選擇只有利用Form的Hidden類型。正如下例：

<HTML>

<HEAD><TITLE>Form

<BODY>

Username=

傳參示例</TITLE></HEAD>”Bill Gates”

<FORM METHOD=

<INPUT Name=

<input type=

</Form>

</Body>

</HTML>

”Post” Action=”/nextpage.asp”>”Username” TYPE=”HIDDEN” VALUE=”<%=Username%>”>”submit” name=”下一頁”>這個主頁包括一個HTML Form。其中有一個隱含類型名字爲Username，同時賦予Username變量的值。這個Form也有一個Submit按鈕。當按鈕點擊後，在hiden類型中存放的Username的值將傳遞到下一個主頁上。在下一個主頁進行處理，然後以同樣方式傳遞到另外一個新的主頁上，下面是nextpage.asp的例子：

<HTML>

<BODY>

Username=Request.Form(

<FORM METHOD=

<input name=

<input type=submit value=

</Form>

</Body>

</Html>

下一頁</TITLE></HEAD>“Username”)”Post” Action=”/thirdpage.asp”>”Username” Type=”hidden” Value=”<%=Username%>”>”再下一頁”>

方法結合

這兩種方法實現起來都十分麻煩而且頗爲”費力不討好”，但是，如果偏要不用Cookies和Session變量來傳遞信息，確實也別無良策。同時，這兩種方法確實可以適用於任何瀏覽器。

注意

請注意，如果在任意一頁中沒有進行這種QueryString字段或者hidden類型的Form的處理，那麼這種跟蹤就停止了，不管這是你希望的還是程序上不小心造成的。

一個十分顯著的缺點是不管利用QueryString字段還是利用Hidden Form傳遞信息，安全性都是毫無保證的，這是由於瀏覽器對信息的接受是在幾乎毫無屏障的情況下進行的。

你完全可以將這兩種方法結合起來，而在接受時可以沒有任何區別，這裏面補充的是，對於Response對象，可以不指定Form集合和QueryString集合來進行接受，這時系統會自動辨認。見下面這個例子：

<HTML>

<BODY>

Username=Request(

<!---

<Form Method=

<input name=

<input type=Submit value=

</FORM>

</BODY>

</HTML>

下一頁</TITLE></HEAD>“Username”)注：就是上面這個腳本，QueryString和hidden的Form都可以正確接收--->”Post” Action=”/nextpage.asp”>”Username” Type=”Hidden” Value=”<%=Username%>”>”下一頁”>點擊這裏</a>在這個例子中，變量Username被賦值而無須知道上一頁是利用的Hidden form域還是QueryString來傳遞參數。在以後編制Active Server Pages時，這種 Request(“Username”)形式的簡易調用將十分常用。

總結

在這章裏面，你應當學到了怎樣利用Sessions進行信息處理，首先你學到的是創建一個Session和用它在多主頁間存儲和傳遞信息，同時你應當掌握在Session開始和結束時創建相應腳本程序，這樣做對於進行統計太重要了。同時，你還學會了和Session密切相關的，創建和讀取Cookies信息。最後，對於那些實在不願意使用Session和Cookie的人們提供了一些替代手段的介紹和討論。 “User”).HasKeys %>當前瀏覽器，是否發送一個Cookie在URL是區分大小寫的,因此，微軟提醒你最好使用同樣的大小寫方式，例如一起使用/WWW/mypage.asp和/www/mypage.asp肯定會使瀏覽器出錯。 “HTTP COOKIE”) %>這個例子中，當用戶的Session開始時，日誌文件中記錄了該用戶的Session和Starting信息；當用戶的Session結束時，日誌文件就記錄了該用戶的Session結束的信息。這樣，你就可以作很多種判斷統計，例如說每個人的停留時間、站上現在有多少人等等。這樣對於站點設計和定位就很有助益。這個用戶自動編號爲<%=SessionID %>這個用戶自動編號爲<%=SessionID %>Session變量，Username和Usercompany，然後，依次通過FOR EACH和FOR...NEXT循環的方法將這兩個字段內容顯示出來，和前面的章節中十分類似“Myname”)=Response.form(“Username”)“Mycompany”)=Response.form(“Usercompany”)很明顯，對於不同的用戶，Session的Myname變量和Mycompany變量各自是不同的，在每個人在網站的不同主頁間瀏覽時，這種針對這個個人的變量會一直保留，這樣作爲身份認證是十分有效的。最後，Sessions還可以用來跟蹤訪問者的習慣，就象現在環境學者跟蹤大白鯊生活習性一樣。你可以跟蹤你的訪問者從一個主頁到另一個主頁，這樣對於你對站點的更新和定位是非常有好處的。