ASP.NET的高级配置Web.config和Machine.Config

  我们都知道,使用ASP是不需要也没有地方可以配置的(IIS配置除外),因此,我们不能针对一些特定的网站应用或者特定的网站目录,设置一些特殊配置,可以这样说,ASP的应用,是比较“傻瓜化”的,网站设计者对网站,理解并使用ASP.NET的高级配置只能通过程序而不能通过系统配置来实现对网站的有效管理。
  和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的登录对话框(图二)


当用户通过验证以后,将见到以下页面(图三),在这个页面中,显示了登录用户的信息:

Response.Write("Windows identity:"+System.Security.Principal.WindowsIdentity.GetCurrent().Name);


以上的设置可以在该应用的子目录中实现继承或者重写,例子程序中,根目录包含一个子目录“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中设置新的键,也不能正常运行,同样出现错误信息。 
发布了55 篇原创文章 · 获赞 1 · 访问量 28万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览