理解並使用ASP.NET的進階配置

 

引言： 本文將討論ASP.NET應用的進階配置方法，在文中將討論的一些配置如下：為ASP.NET進程設定獨立的ID標記；配置ASP.NET網站或者網

站目錄的存取權限；處理自訂配置事件等。除了以上提到的問題，本文還將討論從machine.config檔案繼承和重寫部分ASP.NET配置資訊，<Location>標記也將在本文中討論。

 

ASP.NET配置

我們都知道，使用ASP是不需要也沒有地方可以配置的（IIS配置除外），因此，我們不能針對一些特定的網站應用程式或者特定的網站目錄，設定一些特殊配置，可以這樣說，ASP的應用，是比較“傻瓜化”的，網站設計者對網站，只能通過程式而不能通過系統配置來實現對網站的有效管理。和ASP不一樣，ASP.NET通過XML格式的檔案Machine.Config和Web.Config來完成對網站和網站目錄的配置。對於一個網站整體而言，整個伺服器的配置資訊儲存在Machine.Config檔案中，該檔案的具體位置在%system32%\Microsoft.NET\Framework\[版本號碼]\Config目錄，它包含了運行一個ASP.NET伺服器需要的所有配置資訊。當你建立一個新的WEB Project的時候，VS.NET 會自動建立一個WEB.Config檔案，WEB.Config包含了各種專門針對一個具體應用的一些特殊的配置，比如Session的管理、錯誤捕捉等配置。一個WEB.Config可以從Machine.Config繼承和重寫部分備置資訊。因此，對於ASP.NET而言，針對一個具體的ASP.NET應用或者一個具體的網站目錄，是有兩部分設定可以配置的，一是針對整個伺服器的Machine.Config配置，另外一個是針對該網站或者該目錄的Web.Config配置，一般的，Web.Config存在於獨立網站的根目錄，它對該目錄和目錄下的子目錄起作用。

本文將討論的一些具體配置如下：

• <authorization>：訪問授權資訊的配置；

• <identity>：改變ASP.NET應用的背景工作處理序，繼承、重寫和拒絕重寫相同配置；

• <sessionState>：繼承、重寫和拒絕重寫相同配置；

• <appSettings>：重寫和拒絕重寫相同配置；

例子程式

為了說明以上問題，我們建立了一個ASP.NET例子程式ConfigApplication，以下是這個程式的以下詳細資料：

Solution	ConfigApplication.sln
Project Name	ConfigApplication
Language	C#
Build	Release

以片是ConfigApplication的檔案結構：

以下是另外一個網站CustomConfig的一些資訊：

Solution	CustomConfig.sln
Project Name	CustomConfig
File Name	ConfigHandler.cs
Language	C#
Build	Release

<authorization>

WEB.Config中的<authorization>標記使用<allow>和<deny>子標記來實現配置存取控制許可權。在這裡，需要注意的一點是，這裡的存取控制只對ASP.NET本身的資源有用，比如：ASPX、ASMX、ASCX檔案資源，對於非ASP.NET資源，比如ASP、TXT、影像檔等，都不能提供存取控制。以下是實現該配置的標記：

<authorization>

<allow users="comma-separated list of users"

roles="comma-separated list of roles"

verbs="comma-separated list of verbs" />

<deny users="comma-separated list of users"

roles="comma-separated list of roles"

verbs="comma-separated list of verbs" />

</authorization>

以上標記中，<Allow>標記定義可以訪問資源的使用者，<Deny>標記定義不許訪問資源的使用者。比如，以下標記就定義使用者“wcb02h26\Niranjan”可以訪問Web.Config檔案所在檔案夾及其子檔案夾的資源，其他所有使用者均不能訪問該檔案夾的資源（注意使用了<deny users=”*”>標記）。

<authorization >

<allow users="wcb02h26\Niranjan" />

<deny users="*"/>

</authorization>

以上設定可以在ConfigApplication應用的根目錄下的Web.Config檔案找到。在該應用的根目錄下面，有RootFolderForm.aspx檔案，如果使用者訪問該檔案，ASP.NET將調用Windows的登入對話方塊（圖二）

當使用者通過驗證以後，將見到以下頁面（圖三），在這個頁面中，顯示了登入使用者的資訊：

以上的設定可以在該應用的子目錄中實現繼承或者重寫，例子程式中，根目錄包含一個子目錄“Subfolder1”，現在，讓我們來看看怎樣實現使用者“wcb02h26\Niranjan”不能訪問“Subfolder1”，但是；另外一個使用者“wcb02h26\test”卻可以訪問。為了實現重寫配置，我們需要在目錄“Subfolder1”的根目錄添加一個WEB.Config設定檔：

<?xmlversion="1.0"encoding="utf-8"?>

<configuration>

< system.web >

<! -- For authorization code -- >

< authorization >

< allow users ="wcb02h26\test" />

< deny users ="*"/>

</ authorization >

</ system.web >

</configuration>

當我們訪問“Subfolder1”目錄下的“SubFolder1Form.aspx”檔案的時候，ASP.NET將調用Windows登入對話方塊，並且只許使用者“wcb02h26\test”訪問。然而，特別需要注意的是，以上的配置並不能對影像檔等非ASP.NET資源起作用，也就是說，我們不能期望非ASP.NET資源也可以受到存取控制。

除了使用上面提到的“User”標記以外，如果我們需要對一組使用者實現存取控制，就可以使用“roles”標記，使用“Verbs”標記，我們還可以對訪問類型進行控制。以下的舉例，實現wcb02h26電腦的所有Administrator組使用者自由訪問根目錄下的ASP.NET資源，但是任何人都不能從頁面提交（Post）資訊給伺服器。

<?xmlversion="1.0"encoding="utf-8"?>

<configuration>

< system.web >

<! -- For authorization code -- >

< authorization >

< allow roles ="wcb02h26\administrators" verbs ="GET"/>

< deny users ="*" verbs ="POST"/>

</ authorization >

</ system.web >

</configuration>

以下是頁面SubFolder2Form.aspx的運行（圖四）：

如果使用者點擊“Submit”按鈕提交資訊，將出現以下錯誤頁面（圖五）：

如果從以上配置資訊中去掉“<deny>”標記，使用者就可以隨意提交資訊而不會出現錯誤了。

以上我們介紹了對網站資源進行存取控制的一些配置，特別需要注意的是，和ASP中通過資料庫實現存取控制一樣，這裡的資源存取控制，也只針對專門的ASP.NET 資源，非ASP.NET 資源，瀏覽者是可以隨意訪問的。

<identity>

這個標記用來控制ASP.NET應用的“身份”，以下是這個標記的具體使用：

<identity impersonate="true|false"

userName="username"

password="password"

/>

<identity>標記決定ASP.NET應用使用哪一個使用者帳號來運行，在Machine.Config中，預設的， impersonate是設定為“False”的。當調用根目錄下的RootFolderForm.aspx檔案的時候，會將程式使用的使用者顯示出來（圖六）：

以上的設定可以通過修改Machine.Config檔案來實現，開啟該檔案，並將相關內容修改如下：

<identity impersonate="true"

userName="wcb02h26\Niranjan"

password="venezia143"/>

當運行RootFolderForm.aspx的時候，將得到一個錯誤資訊，指明“identity”不能被修改。這是因為，預設的，ASP.NET不能將進程委派給別的使用者，為瞭解決這個問題，我們必須修改本地安全性原則。開啟“管理工具”->“本地安全性原則”，點擊“本地策略”檔案夾下的“使用者權利指派”，雙擊“作為服務登入”並增加“ASPNET”帳號，參照（圖七）設定。重新啟動伺服器，當再次運行RootFolderForm.aspx的時候，將看到顯示出“wcb02h26\Niranjan”。

這裡，Identity可以針對不同的具體應用設定不同的值，下面我們為“ConfigApplication”設定不同的值，對Machine.Config作以下修改：

修改Identity值為True：<identityimpersonate="true"/>

增加以下內容到Machine.Config檔案的<system.web>標記末尾，<configuration>標記前面。

<locationpath="Default Web Site/ConfigApplication" allowOverride="false">

< system.web >

< identity impersonate ="true" userName ="wcb02h26\Niranjan" password ="venezia143" />

</ system.web >

</location>

以上的“Location”部分可以通過“Path”設定特定WEB應用的Identity，“allowOverride”可以設定是否可以被應用的WEB.Config設定重寫。在我們的舉例中，我們使用使用者“wcb02h26\Niranjan”運行ASP.NET，因為“allowOverride”設定為“False”，所以，這個設定不能被Web.Config重寫，這樣設定以後，當運行RootFolderForm.aspx的時候，我們看不出和上面提到的有什麼區別，修改Web.Config檔案的相關部分：

<identity userName="wcb02h26\test" password="test123"/>

這時再運行頁面，將看到以下錯誤資訊（圖八），這時，就是“allowOverride="false"”這個設定生效了：

<SessionState>

SessionState用來儲存ASP.NET應用的Session資訊，在這裡，我們不討論具體的Session應用等問題，而是重點關注Machine.Config的有關Session的一些設定怎樣允許和不允許某一個具體應用的Web.Config重寫的問題。

<Location>標記允許我們為一個具體的程式設定獨立的值，allowOverride屬性用來定義所有針對ASP.NET的設定都在機器層面起作用，而不能被具體程式的WEB.Config所改變。Machine.Config設定檔案和Web.Config設定檔案中，<sessionState>的預設設定如下：

<sessionState

mode="InProc"

stateConnectionString="tcpip=127.0.0.1:42424"

sqlConnectionString="data source= 127.0.0.1;userid=sa;password="

cookieless="false"

timeout="20"

/>

現在，我們修改以上預設設定，為程式“ConfigApplication”設定一些特殊的值：

<sessionState

mode="StateServer"

stateConnectionString="tcpip=127.0.0.1:42424"

timeout="60"

/>

以上的設定儲存程式的Session保留時間長為60分鐘，如果管理員希望以上的設定不被具體的應用所重寫，他就必須在以上的<Location>段增加一個allowOverride屬性，並且，將這個屬性的值設定為“False”。以下是程式“ConfigApplication”中與Session有關的一些設定：

<!-- For "Default Web Site/ConfigApplication" application -->

<locationpath="Default Web Site/ConfigApplication" allowOverride="false">

< system.web >

< identity impersonate ="true"

userName="wcb02h26\Niranjan"

password="venezia143"

/>

< sessionState mode ="StateServer"

stateConnectionString="tcpip=127.0.0.1:42424"

timeout="60"

/>

</ system.web >

</location>

以上設定的identity段，我們在前面已經詳細討論過，在SessionState段中，設定Session的保留時間為60分鐘，與Machine.Config的設定完全相同。

現在，我們講以上的<SessionState>段全部刪除，運行RootFolderForm.aspx頁面，可以發現，頁面可以正常無誤的輸出。現在，修改Web.Config中<SessionState>部分的值，繼續運行RootFolderForm.aspx頁面，我們發現出現以下錯誤資訊（圖九）：

但是，如果Machine.Config的“allowOverride”屬性設定為“True”，即使在應用的Web.Config中修改了相關設定，也不會出現以上的錯誤資訊頁面，而且，Web.Config中的設定將發生作用，而Machine.Config中的設定將不再有效。

<appSettings>

本節我們將介紹怎樣繼承和重寫Machine.Config中的<appSettings>設定。以下是Machine.config中，針對程式“ConfigApplication”的一些專門設定，注意設定中“allowOverride”屬性是設定為“False”的。

<!-- For "Default Web Site/ConfigApplication" application -->

<locationpath="Default Web Site/ConfigApplication" allowOverride="false">

< system.web >

< identity impersonate ="true"

userName="wcb02h26\Niranjan"

password="venezia143"/>

< sessionState mode ="InProc"

stateConnectionString="tcpip=127.0.0.1:42424"

sqlConnectionString="data source=127.0.0.1;user id=sa;password="

cookieless="false"timeout="30"/>

</ system.web >

< appSettings >

< add key ="myKey" value ="Value from machine.config" />

</ appSettings >

</location>

在以上的設定中，我們發現有一個新增加的鍵“myKey”，它的值為“Value from machine.config”。在頁面RootFolderForm.aspx中，我們在Page_Load部分增加以下程式碼片段：

// For <appSettings>

string strValue = System.Configuration.ConfigurationSettings.AppSettings["myKey"];

Response.Write("<h1> Value of myKey = " + strValue + "</h1>");

運行RootFolderForm.aspx頁面，我們可以看到，“Value from machine.config”顯示在頁面上（圖十）。

由這裡我們可以發現，加入Page_Load中的代碼其實就是顯示MyKey這個鍵的值。

現在，在程式的WebConfig.config部分，我們同樣增加一個MyKey鍵，將它的值設定為“Value from web.config”，以利於區別。

<appSettings>

< add key ="myKey" value ="Value from web.config" />

</ appSettings >

再一次運行頁面，將出現錯誤資訊（圖十一）：

因為在Machine.Config中，我們已經設定“allowOverride”為“False”，這樣，當Web.Config中設定同樣的鍵時，就出現了錯誤。我們可以將Machine.Config中的“allowOverride”設定為“True”，再一次運行頁面，將不會出現錯誤資訊，Web.Config中設定的值也會正常顯示（圖十二）：

另外，當Machine.Config中的“allowOverride”設定為“False”以後，即使在Web.Config中設定新的鍵，也不能正常運行，同樣出現錯誤資訊。