理解并使用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中设置新的键，也不能正常运行，同样出现错误信息。