成員關系的概念在人類社會中是一個層次比較低的概念,源于希望屬于某個群組的意識。我們希望能覺得自己是某個團隊的一部分,讓别人知道我們是誰,是以Web搭上這個流行趨勢,采用這個概念隻是時間早晚的問題。如果坐下來想一想曾經登入過多少個站點并在這些站點上儲存了簡單的使用者資訊,可能會發現自己所屬的群組比一開始想象的要多得多。從出售書籍和小器具的站點到讨論擁有一輛Ford Puma的好處的社群,或者宣傳一個名為Look Around You的BBC TV喜劇節目的站點,作者發現自己是會員的站點多得無法一一列舉。接下來就會碰到一個熟悉的困難“登入這個站點要使用哪個使用者名和密碼?”
Web上最成功的站點之一,Amazon.com,一開始隻是一個書店,但後面經營的範圍越來越大。現在當使用者登入Amazon時,将發現整個頁面上全是與該使用者的消費習慣有關的商品。
在本章中,您将學習怎樣使用ASP.NET 2.0提供的成員關系功能實作站點的個性化。本章讨論如下内容:
● 身份、驗證和授權的概念
● 成員關系伺服器變量,包括Login控件
● 儲存成員配置檔案以便取回
● 在站點的特定部分實施通路限制,隻運作特定的成員通路
● 根據目前使用者配置檔案個性化站點
還将擴充Wrox United示例站點,以便能夠登入該站點并根據一組儲存起來的個人偏好個性化站點,這些資訊是基于成員配置檔案的。
4.1 安全基礎知識
在開始開發涉及到成員關系的應用程式時,必須首先了解幾個關鍵的概念,這些概念是身份、驗證和授權。
4.1.1 身份——我是誰
在考慮身份時,我們可以用幾種獨一的特性來描述自己。例如,我是一個頭發金黃的女人,喜歡看科幻電影群組裝PC機,但這些資訊對于對我的羽毛球技術感興趣的人來說并不是必需的。儲存在站點中的身份資訊很可能隻與一個人的某些方面相關。例如,一個購物站點會儲存使用者的姓名、電話号碼、電子郵件位址和家庭位址,這些資訊都與商品的銷售有關。它們可能不會關心您的個人興趣(除非它們和Amazon的規模一樣大),是以它們并不需要儲存關于使用者的這類資訊,但是這并不妨礙它們擁有這些方面的身份資訊。
是以身份,也就是我是誰的概念,是一組範圍很廣的實際情況的集合。您可能曾經在履歷裡寫下了很多實際情況,但這些情況同樣隻與潛在的雇主相關。在履歷中儲存和删除哪些情況由自己決定。在儲存一個站點的成員的資訊時,情況也是一樣的,必須在開發階段就确定要儲存成員的哪些實際情況。
4.1.2 身份驗證——這就是我
在試圖登入一個網站的時候,使用者要輸入某些證書;例如,郵件位址及其密碼的組合。網站接下來必須判斷使用者是否就是自己聲明的那個人,是以使用者輸入的郵件位址和密碼的組合必須與儲存在伺服器檔案中特定的郵件位址和密碼組合相比對。
身份驗證的過程就是證明自己是自己所聲明的那個人的過程。很多站點,不論它們是零售商品還是提供社群服務,都使用郵件位址和密碼的組合作為身份驗證方法,這是一種經過反複考驗的方法。雖然這種方法不是絕對安全,但是隻要選擇一個足夠可靠的密碼并嚴格保密,同時站點的代碼經過嚴格的測試,那麼使用者的配置檔案将隻能由使用者本人使用。
4.1.3 授權——這是我能做的
在向網站輸入使用者名和密碼之後,Web伺服器将不僅會驗證密碼和使用者名是否比對,還将檢視站點管理者給使用者授予了什麼權限。身份驗證之後的下一個步驟是授權,這個步驟将檢索您所擁有的使用者賬戶類型的更多資訊。
例如,以一個銀行網站為例。在使用者的登入資訊通過驗證之後,伺服器将檢視使用者在該站點上的權限。與大多數使用者一樣,您可以查詢賬戶、在賬戶之間轉賬或者支付賬單。然而,如果銀行受到某個安全方面的恐吓(類似于Internet上到處流傳的網絡釣魚(phishing)電子郵件),您可能會發現自己突然無法通過這個線上應用程式添加任何第三方代理訂單,直到安全危機解除為止。功能的關閉很可能是由管理者為一些或所有使用者設定一個特殊的标記而進行控制的,在頁面上告訴使用者他們不再有權限修改他們賬戶的詳細資訊。
4.1.4 登入站點
登入站點的過程,從使用者的角度看,就是輸入一組證書,然後根據自己的配置檔案看到不同使用者界面的過程。通常,使用者所使用的證書是使用者名加密碼的組合;然而,對于安全性更高的站點,例如銀行站點,可以使用其他的方式登入,包括PIN和安全認證。如果不考慮向伺服器傳送身份驗證證書的方法,那麼身份驗證的基本原則是一樣的。一旦驗證完成之後,通過身份驗證機制查詢使用者具有什麼樣的權限就比較簡單了。
撇開理論,ASP.NET 2.0提供了一些非常強大的工具,可以幫助開發人員以最小的代價實作登入-身份驗證-授權架構。在舊版的ASP.NET中,開發人員必須編寫代碼實作登入、根據資料庫進行驗證并根據目前登入的使用者做出響應。雖然開發人員最終仍要編寫代碼對使用者進行處理(如本章後面的内容所示),但是一些強大的控件和向導已經把這個過程起始階段的各種困難都解決了。在這一節中,将進一步學習用于處理登入的伺服器控件和ASP.NET Web Application Configuration實用工具。
4.2.1 Login控件
在本小節中,首先将建立一個隻有兩個頁面的簡單模拟站點;Default.aspx是前台頁面,login.aspx是登入頁面。您将進行一系列的練習,然後暫停下來檢視幕後發生的是什麼。在本章的後面,将把其中一些規則應用到Wrox United站點以便把登入架構整合到這個應用程式中。
這一節介紹以下幾個控件:
● Login控件,該控件提供文本框、按鈕和内建的身份驗證功能,使開發人員通過簡單的拖放操作就可以向頁面添加登入功能。
● LoginView控件,該控件根據使用者是否登入可以改變頁面的外觀,或者向不同群組的使用者顯示不同的頁面。
● LoginStatus控件,該控件向使用者顯示回報資訊,提醒使用者他們是否已經登入站點。
在下面的“試一試”練習中,将使用以上的一些控件。這個示例通過建立頁面并添加控件來搭建站點的骨架。
(1) 打開VWD并在C:/BegASPNET2/Chapters/Begin目錄中建立一個空白的站點,将其命名為Chapter04。預設情況下,站點中應該已經包含了一個名為Default.aspx的頁面,如圖4-1所示。
圖 4-1
(2) 再添加控件。切換到Design View,從工具箱的Login面闆中将LoginView控件拖放到頁面上(如圖4-2所示)。在彈出的Common Tasks菜單中,確定選擇Anonymous Template并在主文本框中輸入You are not logged in。
圖 4-2
(3) 通過單擊該控件右上方的小箭頭再次打開Common Tasks菜單并選擇LoggedInTemplate,然後在文本框中輸入You are logged in。這将確定頁面提醒使用者是否已經登入。
(4) 将一個LoginStatus控件拖放到頁面上并放置在LoginView控件的下面,如圖4-3所示。這個控件将根據使用者目前是否已經登入向使用者顯示一個登入或登對外連結接。
圖 4-3
(5) 下一步要建立一個登入頁面,是以在Solution Explorer中單擊站點的根目錄并選擇Add New Item。在彈出的對話框中,選擇Web Form并命名為Login.aspx,如圖4-4所示。
圖 4-4
(6) 在這個新建立的頁面中,從工具箱的Login面闆上拖放一個Login控件到該頁面上,如圖4-5所示。
(7) 在彈出的Common Tasks菜單中,可以管理站點。到現在為止,整個架構已經搭建完畢,但在站點能夠運作之前需要添加一些使用者賬戶,是以請單擊Common Tasks菜單中的Administer Website連結啟動ASP.NET Web Application Configuration工具,該工具将在下一個練習中介紹。
圖 4-5
操作回顧
這些控件确實非常強大,雖然現在還不能運作這個示例,但是完全可以相信,隻需再進行少量的處理,就可以獲得一個能夠試驗登入功能的完整的(目的非常單純的)站點。這些控件是在ASP.NET 2.0中新增加的;在以前,開發人員必須手動添加文本框、按鈕并編寫VB.NET或者C#代碼來處理這個過程、顯示使用者是否登入的消息、以及根據目前的使用者改變頁面。到目前為止,您所需做的就是向頁面中拖放一些控件,這就是搭建一個應用程式的架構必須完成的所有工作。
現在,讓我們來看看添加到頁面中的控件,從Default.aspx頁面開始。
在Source View中檢視Default.aspx頁面将看到如下代碼:
<asp:LoginView ID="LoginView1" Runat="server">
<LoggedInTemplate>
You are logged in
</LoggedInTemplate>
<AnonymousTemplate>
You are not logged in.
</AnonymousTemplate>
</asp:LoginView>
<asp:LoginStatus ID="LoginStatus1" Runat="server" />
在代碼中可以看到兩個已定義的控件:用于顯示登入資訊的LoginView控件和用于控制登入與登出過程的LoginStatus控件。注意如果按照本例進行配置,将無法看到匿名模闆消息,因為匿名使用者沒有通路站點的權限(而是被直接導航到登入頁面)。
在Login.aspx頁面中,将看到如下已添加的代碼:
<asp:Login ID="Login1" Runat="server">
</asp:Login>
幾乎不用編寫任何代碼!所有的功能都已事先編寫好,是以不會看到任何文本框,也不會看到任何身份驗證代碼—— 而隻是看到一行代碼。ASP.NET 2.0中提供工具讓開發人員自己建立類似這種複雜的控件,但這個内容超出了本章的讨論範圍。
在前一個練習的第7步中單擊管理連結之後,VWD中将顯示如圖4-6所示的頁面(注意每回第一次啟動這個站點的時候端口号都将不同)。
圖 4-6
(1) 單擊Security連結顯示Security設定管理頁籤,如圖4-7所示。
圖 4-7
(2) 該頁面上有一個超連結,單擊該連結可以啟動Security Setup Wizard。單擊該連結進入向導的第一步,如圖4-8所示。
圖 4-8
(3) 單擊Next跳過這個頁面,并進入如圖4-9所示的界面。選擇From the Internet單選按鈕允許匿名使用者和已登入的使用者通路這個站點。
圖 4-9
單擊Next進入下一步,如圖4-10所示。
圖 4-10
可以直接跳過該頁面并單擊Next繼續—— 預設的提供商将提供所有的功能。在下一個界面中,向導會詢問是否希望為站點定義角色。在這個示例中,可以跳過這一步—— 本章的後面将定義角色。不要選中複選框并單擊Next。
(4) 在到達下一個界面之後,該向導将提示輸入使用者的一些詳細資訊,如圖4-11所示。
圖 4-11
(5) 如圖4-12所示,輸入站點的某個使用者的詳細資訊—— 這可能是您的姓名、我的姓名或者是其他任何人的姓名!隻要别忘記所輸入的密碼就行—— 後面要用到這個密碼。單擊Create User按鈕将顯示一個确認提示,此時可以單擊Continue建立另一個使用者。到現在為止,已建立了兩個使用者—— 一個标準使用者和一個後面将用作站點管理者的使用者。
圖 4-12
在後面的練習中,将為這些使用者指定恰當的站點通路權限。注意現在還不能為使用者指定任何角色—— 這将在後面的安裝過程中完成。單擊Next繼續。
(6) 下一步是為站點定義權限級别,定義誰能看到站點的内容,誰不能通路站點。在這個步驟中,可以直接為使用者添權重限。在後面,将把這些使用者添加到不同的群組并為整個群組的使用者賦予權限。如圖4-13所示,需要為每個使用者單獨賦予Allow權限,并拒絕所有的匿名使用者。為了設定某個使用者的權限,首先選中User單選按鈕,在該按鈕後面的文本框中輸入使用者名,選擇Allow,并單擊Add This Rule。要拒絕匿名使用者通路,選中Anonymous Users單選按鈕,在Permission區單擊Deny,并單擊Add This Rule。
在單擊Next之後,向導也将完成,這意味着現在有了一個擁有一些使用者配置檔案和通路權限級别的站點。現在就隻剩下運作頁面了!
(7) 傳回VWD,按下Ctrl+F5運作Default.aspx頁面—— 将看到如圖4-14所示的畫面。
由于匿名使用者無法通路站點,是以站點直接顯示登入頁面。注意頁面的位址,該位址表明要檢視的是Default.aspx頁面。
(8) 在登入之前,試着輸入一些不合法的證書(一個不存在的使用者名和密碼,但密碼不能為空)。将看到如圖4-15所示的畫面。
圖 4-13
圖 4-14
圖 4-15
(9) 現在以一個合法的使用者賬戶登入;站點将自動把您帶回Default.aspx頁面,如圖4-16所示。
圖 4-16
單擊Logout連結将把您帶回Login.aspx頁面—— 這個站點不允許任何未登入的人檢視網頁。
操作回顧
用于ASP.NET頁面的Login控件是Microsoft ASP.NET小組為開發人員準備的禮物。作者已經不記得參與過多少個帶有定制登入功能的站點的開發,每個站點都要編寫代碼實作這個功能,而現在作者所要做的隻是向頁面拖放幾個控件。除此之外,還可以使用向導配置賬戶和權限,進一步簡化開發。您可能希望使用自己的使用者賬戶資料存儲庫,或者甚至連結到活動目錄(Active Directory)使用者賬戶,但這可以在後面的開發過程中修改。
這個練習逐漸介紹了使用者賬戶的配置。雖然這是一個必要的過程,但Website Administration工具在幕後建立的内容更讓人感興趣。首先,建立的使用者賬戶配置檔案必須儲存在某個中心存儲庫,是以該工具為這個目的建立了一個新的配置檔案資料庫。檢視C:/BegASPNET2/Chapters/Begin/Chapter04目錄會看到一個名為App_Data的檔案夾。單擊右鍵并選擇Refresh(重新整理)檔案夾,應該看到一個名為AspNetDB.mdf的檔案。這是一個Microsoft SQL資料庫檔案,可以在VWD的開發環境中檢視這個資料庫表格的結構和内容,如圖4-17所示(在學習資料庫章節的時候将了解到這個過程的更多内容)。
圖 4-17
配置的另一個部分是為使用者賬戶賦予一定的權限以便他們能夠通路站點。通過使用向導,這個過程可以變得很容易。在向導完成之後,解決方案中就新增了一個名為Web.config的檔案(儲存在伺服器上以偏愛的方式運作站點的配置檔案—— 詳細内容請參閱第2章)。如果檢視Chapter04檔案夾中的Web.config檔案,将看到如圖4-18所示的語句。
圖 4-18
注意這個配置檔案中的<allow…/>和<deny…/>之間的内容反映了我們在示例中設定的權限。可以手動直接添加和修改這些語句,或者使用Administration Tool使這個過程流程化,兩種方式都可以。
值得注意的是,LoginView控件除了根據使用者是否已經登入顯示特定的文本以外還可以完成很多功能。在第11章中,您将看到使用這個控件不僅基于使用者的身份,而且基于使用者的角色來改變整個頁面的外觀。這個控件可以包含文本、HTML甚至其他控件。下一個“試一試”練習中将進行示範。
4.2.2 個性化
站點個性化以反映目前登入使用者的偏好是實作社群化和歸屬感的一種好方法。雖然本章不會進行很多個性化處理,但在下一章本書将讨論一些ASP.NET開發人員提供的功能,這些功能可以為使用者提供更加個性化的使用者界面和浏覽體驗。
對于任何個性化的站點,一個有用的附加功能是向已登入的使用者通過某種類型的回報資訊,告訴使用者站點已經正确地确認了他們的身份。LoginName控件是添加這種功能的簡單方法。在下面的“試一試”練習中,您将了解到如何使用這個控件。在這個示例中,需要授權匿名使用者通路站點。
(1) 可以選擇任何一種喜歡的方式為匿名使用者授權—— 要麼編輯Web.config檔案(參考前面的“操作回顧”),要麼啟動Web Site Administration Tool。要再次啟動這個工具,可以在系統托盤中右擊管理站點圖示并選擇Open in Web Browser。或者,如果選中修改Web.config檔案,隻需在VWD中打開該檔案并修改代碼中的灰色部分:
<authorization>
<allow users="?" />
<allow users="administrator" />
<allow users="chrishart" />
</authorization>
問号表示所有匿名使用者,是以通過将deny改為allow,啟用匿名通路。
(2) 接下來需要對網頁代碼進行少量的修改以便添加LoginName控件。打開Default.aspx頁面并彈出LoginView控件的Common Task菜單(單擊該控件右上方的小箭頭并選擇LoggedInTemplate,如圖4-19所示)。将文本修改為You are logged in as,然後将一個LoginName控件拖放到文本的結尾處。
圖 4-19
(3) 在将LoginName控件添加到頁面之後不需要對其進行任何修改,是以現在就可以儲存修改并運作頁面了。首先看到的是一個匿名使用者通路站點時的頁面,如圖4-20所示。
圖 4-20
現在單擊Login連結并登入站點。登入成功之後,應該可以看到類似圖4-21所示的頁面,具體内容與登入所使用的使用者賬戶有關。
圖 4-21
操作回顧
使用LoginName控件在頁面上顯示目前登入使用者的身份是一種快捷簡單的方法。如果切換到該頁面的Source View,就可以看到LoginName控件,如下代碼灰色部分所示:
<LoggedInTemplate>
You are logged in as
<asp:LoginName ID="LoginName1" runat="server" />
<br />
</LoggedInTemplate>
在作者的代碼中增加了一些HTML代碼;因為我在LoginName控件之後按下了Return(以便LoginStatus控件能顯示在下一行),在代碼中出現了一個<br / >HTML标記。這是一個簡單的HTML換行代碼。在從Design View切換到Source View之後,開發人員經常可以看到類似的标記添加到代碼中。最常見的兩個符号是 和<br / >; 是一個不可中斷的空格(這個空格将和緊靠在它前面和後面的内容顯示在同一行上),而<br / >是一個簡單的換行符。這個示例的重點不是HTML代碼,而是LoginName控件的源代碼。同樣,在産生的代碼中也沒有任何讓人興奮的内容,因為ASP.NET在幕後完成了尋找目前登入使用者名稱的重任,并在伺服器呈現頁面的時候将其插入到頁面中。
注意并沒有将LoginName控件添加到Anonymous模闆中,其實也沒有理由要這樣做—— 如果作為匿名使用者通路站點,該控件不會顯示任何資訊。
到現在為止您已經花了一定的時間試驗使用者賬戶和站點登入。在本章的前面,我們已經讨論過角色的概念。下一小節将介紹角色是什麼以及怎樣使用角色細化站點成員的特征。
4.2.3 成員關系
定義哪些使用者可以通路站點對于一個小型的站點來說是完全可行的,但站點必須非常小而且規模必須保持在一個可管理的範圍内。一種更好的解決方案是定義一組使用者角色,然後将使用者賬戶添加到恰當的角色中。一旦使用者成為某個角色的成員之後,就可以基于角色為使用者授權。
例如,考慮一個典型的站點配置情景:Administrators角色的所有成員可以通路站點,而且可以通路站點的所有部分。Users角色的所有成員可以通路該站點,但不能通路某些受限的部分。所有匿名使用者都将看到裁減過的頁面,但沒有任何個性化資訊,而且理所當然不能通路受限的部分。
第11章将更詳細地讨論角色,包括充分利用角色細化Wrox United站點。同時,在下面的“試一試”練習中可以體驗到角色的作用,因為其中将擴充Chapter04示例包含角色。在這個示例中将定義兩種角色:Users和Administrators。在向角色添加使用者之前必須先建立這些角色。
(1) 先再次啟動Web Site Administration Tool。如果最近曾經使用過這個工具,那麼可以右擊系統托盤中該工具的圖示并選擇Open in Web Browser。或者,可以在VWD的主菜單條中選擇Website→ASP.NET Configuration。在打開該工具之後,選擇Security頁籤并單擊Enable Roles連結,如圖4-22所示。
圖 4-22
(2) 接下來應該可以單擊Create or Manage Roles連結。單擊該連結進入Create New Role界面。在這裡,需要建立兩個角色:users和administrators,在文本框中輸入角色的名稱并單擊Add Role即可(如圖4-23所示)。
圖 4-23
(3) 單擊Administrators群組的Manage連結,然後搜尋Administrator使用者賬戶,使用如圖4-24所示的搜尋工具。搜尋Administrator賬戶最簡單的方法是搜尋所有以A開始的賬戶,是以在文本框中輸入a*并單擊Find User。隻要選中User Is In Role複選框即可将Administrator賬戶添加到Administrators角色中。
圖 4-24
(4) 以相同的方式把其他使用者賬戶添加到Users角色中。
(5) 單擊Security頁籤傳回到管理工具的主要Security區域。進入該頁籤之後,單擊Manage access rules連結傳回管理站點通路規則的頁面。在前面的示例中已經使用過相同的界面管理通路規則(如圖4-13所示),現在删除單個使用者的通路規則,取而代之為Administrators和Users兩個群組賦予權限。在删除規則時,将看到如圖4-25所示的提示。
圖 4-25
接下來可以在如圖4-26所示的界面中依次為每個角色添加新的權限。
圖 4-26
在添加好規則後,應該可以看到如圖4-27所示的規則清單。
圖 4-27
(6) 如果現在再次運作這個應用程式,應該可以像原來一樣使用相同的使用者賬戶登入站點。如果修改某個角色的權限,那麼角色中的所有成員都将受到影響,是以可以限制所有非管理者使用者的通路權限。
操作回顧
這個示例中所做的修改都是在強大的Web Site Administration界面中完成的,這個工具簡化了添加角色定義和通路規則的過程。如果要手動完成所有修改,如稍後所示,則必須修改前面見過的AspNetDB.mdf資料庫中Roles表格的内容,然後通過手動修改UsersInRoles表格的内容向這些角色添加使用者。接下來必須修改Web.config檔案以改變站點的存取權限。
這個工具将自動化地完成整個配置過程,是以配置和管理都變得更加簡單!然而,這是Visual Web Developer和Visual Studio 2005的功能,而不是ASP.NET的功能,是以如果不能使用VWD開發環境,那麼必須手動執行這些操作。
如果傳回到Web.config檔案的Source View,将看到其中發生了如下改動(灰色部分):
<roleManager enabled="true" />
<authorization>
<allow users="?" />
<allow roles="administrators" />
<allow roles="users" />
</authorization>
另外,添加角色的過程也使使用者配置檔案資料庫發生了少許改變,在該資料庫中新增了兩個表:一個用于儲存角色,另一個使用者記錄使用者分别屬于哪個角色(如圖4-28所示)。
圖 4-28
4.2.4 身份驗證
一個尚未讨論的問題是應用程式的身份驗證是如何實作的,以及ASP.NET為身份驗證提供了哪些選擇。到目前為止,所有示例都依賴一種稱為Forms身份驗證的技術。那麼,什麼是Froms身份驗證,其他的身份驗證技術有哪些?
● Forms身份驗證:要發出登入請求,需要在網頁上填寫一個表單并将該表單送出到伺服器。伺服器在接受該請求之後,将向使用者的本地機器寫一個cookie,在後續的浏覽中,浏覽器每次發送請求時都會将該cookie送回伺服器,這樣使用者就可以根據自己的希望保持身份驗證狀态。
● Windows身份驗證:登入頁面将使用者證書發送到Web伺服器(隻能是IIS,而不是VWD内建的Web伺服器)。然後Web伺服器使用應用程式所運作的虛拟目錄配置的方法處理身份驗證。IIS連接配接到Windows作業系統和Active Directory(活動目錄)域結構上,這意味着它依賴于存儲在站點外部的使用者配置檔案,并使用标準Windows證書登入到站點。根據站點的配置情況以及登入計算機所使用的賬戶,甚至可以不用直接登入站點,因為目前所使用的Windows證書會自動傳遞到Web伺服器進行身份驗證。這種方式在開發區域網路應用程式時特别有用。
● Passport身份驗證:登入證書被傳遞到某個Microsoft Passport伺服器,這個伺服器集中儲存了使用者的配置檔案。登入Hotmail賬戶使用的就是這種方式。由于可以配置Windows在啟動時登入一個Passport賬戶,是以在通路Hotmail收件箱時甚至都不需輸入密碼。
Forms身份驗證模式
本節讨論Forms身份驗證的工作原理。考慮以下情景:
● 使用者—— 假設是Bob—— 希望檢視頁面A,匿名使用者不可以通路這個頁面,是以當Bob試圖通路頁面A時,浏覽器取而代之顯示一個登入頁面,如圖4-29所示。
圖 4-29
● Bob現在面對着登入頁面。由于Bob以前已經在該站點上注冊過,是以他使用他的使用者名和密碼組合登入這個站點。圖4-30顯示了Bob的浏覽器和伺服器之間的互動過程。
圖 4-30
● Bob現在可以浏覽頁面A并是以感到高興。現在Bob希望通過頁面A上的一個連結檢視頁面B。在發送該頁面的請求時,Bob的浏覽器同時将cookie的一個副本發送到伺服器,讓伺服器知道是Bob想要檢視這個頁面。伺服器知道Bob的身份,而且喜歡Bob,是以根據請求将頁面B發送給Bob,如圖4-31所示。
圖 4-31
● 如果Bob現在請求站點的首頁,浏覽器仍會将cookie和請求一起發送到伺服器,是以即使首頁不是受限的内容,cookie仍會被傳遞回伺服器。由于首頁沒有受到限制,伺服器不會考慮cookie,直接忽略它并将首頁發送給Bob。
● Bob接着傳回頁面A。因為Bob機器上的cookie仍然是有效的,是以該cookie仍會被送回伺服器。伺服器也仍然喜歡Bob,是以它允許Bob浏覽這個頁面。
● Bob離開計算機并享受了一杯咖啡。然後去吃午飯。當他重新回到計算機前時,已經過了25分鐘。Bob現在希望再次浏覽頁面B,但是他機器上的cookie已經過期了。伺服器在接收頁面請求時沒有得到cookie,是以Bob必須重新登入。
一般都會将使用者機器上的cookie設定為在一定時間之後過期。在上面的情景中,伺服器為cookie指定了20分鐘的有效期,這意味着隻要在20分鐘之内向伺服器發送兩次請求,本地機器上的cookie就将一直保持活動狀态。然而,如果20分鐘之内沒有向站點送出請求,使用者将必須重新登入才能檢視受限的内容。
您将注意到在前面的示例中建立的登入頁面為使用者提供了“remember my details for next time”(記住使用者名)選項。選中該選項将在浏覽器的cookie集中寫入一個有效時間更為長久的cookie,在下次通路這個站點的時候,您的賬戶名将提前顯示在頁面上。由于不應将密碼資訊儲存在cookie中,是以每次登入都必須輸入密碼,但至少不用輸入使用者名字段。
其他的身份驗證方法(Windows身份驗證和Passport身份驗證)提供的終端使用者都比較熟悉。例如,Windows身份驗證模式依賴于Web伺服器(一般情況下都是IIS)來控制站點的通路權限,但也可以同時使用過期機制阻塞空閑了過長時間的使用者。要配置Windows身份驗證,需要指定位于公司Active Directory(AD)域内的哪些使用者或角色可以通路站點。然後這些使用者就可以使用登入公司網絡上的計算機時所用的登入資訊通路站點。
也可以在公司的外部環境中檢視使用Windows身份驗證模式的站點,隻不過在試圖檢視一個由Windows身份驗證模式保護的頁面時必須輸入标準Windows登入證書。
Passport身份驗證模式的普及率沒有Microsoft期望的那麼高,但确實有一些站點連接配接到Passport網絡處理站點的身份驗證(例如,Expedia.com)。Passport身份驗證依賴于存儲使用者賬戶的資料庫,該資料庫可以通過任意線路進行通路,有點類似于儲存Web賬戶的中心Active Directory。
本書使用Forms身份驗證處理Wrox United站點的所有身份驗證。
如果希望在Wrox United站點包含一些個性化資訊,那麼必須為其配置安全政策。已完成的站點中(www.wroxunited.net)具有購物車功能。另外,完成後的站點中還有一個管理區,允許管理者在其中編輯預定日期、修改成員資料等。所有這些都意味着必須在某個階段添加一些使用者和角色—— 由于您已經具有使用配置工具的充足經驗,現在應該可以執行這個過程的第一個步驟。下面的“試一試”練習将帶領您逐漸為Wrox United站點配置使用者賬戶和角色。在這個階段,不必擔心鎖定了站點的部分内容;這是本書後續部分的任務。
(1) 先在VWD中打開本章的Wrox United示例站點。在打開該站點之後,單擊Website菜單并選擇ASP.NET Configuration。這将啟動站點的配置工具。圖4-32顯示已完成的站點的配置界面。
圖 4-32
(2) 單擊Security連結進入配置使用者和角色的選項頁。與在本章前面的練習中進行的操作一樣,啟動安全設定向導。在操作該向導的過程中,選擇如下内容:
● 該應用程式将使用在Internet上。
● 激活角色。
● 如果不存在角色,建立以下角色:Administrator、FanClubMember、Manager、Owner和Reporter(如圖4-33所示)。
圖 4-33
● 最後,建立使用者賬戶—— 最少建立5個使用者賬戶以便在每個角色中至少有一個賬戶。Wrox United應用程式預定義的使用者賬戶如圖4-34所示。
圖 4-34
檢視一下完整應用程式的配置可以看到預定義的使用者賬戶分屬于不同的角色,是以ChrisH賬戶是Reporter角色的成員,Jim是Owners角色的成員,而Lou是Fan Club角色的成員。
(3) 向導結束之後,需要在WroxUnited目錄内建立一些子檔案夾,它們将包含站點的特定部分—— Admin和FanClub部分。
(4) 現在可以進入管理Access Rules的區域添加以下規則:
● 對WroxUnited主檔案夾,允許匿名通路。
● 對FanClub檔案夾,首先拒絕所有使用者通路,然後添加一個規則,隻允許FanClub角色的成員進行通路。
● 對Admin檔案夾,拒絕所有使用者通路。
由于現在還不會用到這些使用者賬戶和角色,是以暫時不必對站點進行其他處理。然而,在建立站點的其他頁面時這些準備工作将為以後的工作打下很好的基礎。
操作回顧
在Wrox United應用程式中,可以看到一個功能完整的Web應用程式的配置資訊。可以使用管理工具和Web.config檔案任意檢視這些配置,進而弄清楚這些基本權限是怎麼設定的。這個示例隻是簡單介紹本書後面的内容,因為第11章詳細讨論基于角色的權限控制并介紹其他通過使用角色允許和限制内容的技術。
用于過濾FanClub檔案夾通路權限的代碼已添加到FanClub檔案夾内的Web.config檔案中。如下所示:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<authorization>
<allow roles="FanClubMember" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
注意FanClubMember角色被定義成惟一能夠通路該檔案夾内的内容的角色。
這個示例中建立的目錄級别的權限已經在站點内建立了一個受限區域。第11章将在Administration小節和Fan Club小節中帶領您進行一些練習,示範ASP.NET 2.0技術的不同組成部分。這些示例是基于對本節内容的了解之上的。
本章讨論了安全的基礎内容、身份的概念以及登入站點的過程。有些概念對于任何使用Internet在網上沖浪、參加社群讨論或者線上購物的人來說都是很熟悉的,而且由于這些概念的使用範圍是如此廣泛,是以ASP.NET 2.0專門針對這些功能進行了設計,進而簡化站點的建立工作。
需要了解的核心概念包括:
● Identity:身份,一個個體由一組屬性進行描述,這些屬性保證個體的惟一性。
● Authentication:身份驗證,向伺服器傳送一組證書資訊進而使伺服器辨別使用者的身份。如果伺服器可以辨別試圖進行連接配接的使用者,那麼使用者将通過驗證。
● Authorization:授權,将已認證驗證的使用者證書和一組通路控制規則進行比較,進而針對“這個使用者能夠通路所請求的資源嗎?”這個問題給出答案。
● Personalization:個性化,根據目前登入的使用者提供特定的資訊。
● Membership:成員關系,表示歸屬的概念。本章讨論了使用者屬于特定角色的概念。
下一章将擴充個性化的概念介紹怎樣實作ASP.NET站點的個性化。
(1) 修改本章中Wrox United應用程式的通路權限,允許匿名使用者通路,但拒絕某個特定使用者賬戶通路。
(2) 本章的示例站點中添加一個名為Admin的子檔案夾。在該檔案夾中,添加一個帶有LoginName控件的頁面,将其命名為MainAdmin.aspx,還可以在該頁面上放置其他控件。修改這個檔案夾的通路權限使得隻有Administrators群組的成員能夠通路它。