男人.No boy no cry

彪悍的人生,不需要解釋...

导航

理解并使用ASP.NET的高级配置

Posted on 2005-03-23 08:23  Piccolo Goo  阅读(973)  评论(0编辑  收藏  举报
理解并使用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中设置新的键,也不能正常运行,同样出现错误信息。

AB-ERP DEVELOPED BY TVM All Rights Reserved 2004