web.config中authorization下的location中的path的设置

 

web.config中authorization下的location中的path的设置

项目下 
有三个文件夹 A,B,C 
验正方式是 Forms 验正 
我要设置他们的访问权限为, 
A,匿名可访问 
B,普通用户授权后才能访问 
C,只允许管理员访问 

<configuration> 
<location path= "A "> 
<system.web> 
<authorization> 
<allow users= "* "/> 
</authorization> 
</system.web> 
</location> 
<location path= "B "> 
<system.web> 
<authorization> 
<allow users= "? "/> 
</authorization> 
</system.web> 
</location> 
<location path= "C "> 
<system.web> 
<authorization> 
<allow roles= "Admins "/> 
</authorization> 
</system.web> 
</location> 
</configuration>


Web.config文件是一个XML文本文件，它用来储存 ASP.NET Web 应用程序的配置信息（如最常用的设置ASP.NET Web 应用程序的身份验证方式），它可以出现在应用程序的每一个目录中。当你通过VB.NET新建一个Web应用程序后，默认情况下会在根目录自动创建一个默认的 
Web.config文件，包括默认的配置设置，所有的子目录都继承它的配置设置。如果你想修改子目录的配置设置，你可以在该子目录下新建一个Web.config文件。它可以提供除从父目录继承的配置信息以外的配置信息，也可以重写或修改父目录中定义的设置。 

在运行时对Web.config文件的修改不需要重启服务就可以生效（注：＜processModel＞ 节例外）。当然Web.config文件是可以扩展的。你可以自定义新配置参数并编写配置节处理程序以对它们进行处理。 

二、web.config配置文件（默认的配置设置）以下所有的代码都应该位于 

＜configuration＞ 
＜system.web＞ 
和 

＜/system.web＞ 
＜/configuration＞ 
之间，出于学习的目的下面的示例都省略了这段XML标记 

1、＜authentication＞ 节 

作用：配置 ASP.NET 身份验证支持（为Windows、Forms、PassPort、None四种）。该元素只能在计算机、站点或应用程序级别声明。＜authentication＞ 元素必需与＜authorization＞ 节配合使用。 

示例： 

以下示例为基于窗体（Forms）的身份验证配置站点，当没有登陆的用户访问需要身份验证的网页，网页自动跳转到登陆网页。 

＜authentication mode="Forms" ＞ 
＜forms loginUrl="logon.aspx" name=".FormsAuthCookie"/＞ 

＜/authentication＞ 
其中元素loginUrl表示登陆网页的名称，name表示Cookie名称 

2、＜authorization＞ 节 

作用：控制对 URL 资源的客户端访问（如允许匿名用户访问）。此元素可以在任何级别（计算机、站点、应用程序、子目录或页）上声明。必需与＜authentication＞ 节配合使用。 

示例：以下示例禁止匿名用户的访问 

＜authorization＞ 
＜deny users="?"/＞ 
＜/authorization＞ 
注：你可以使用user.identity.name来获取已经过验证的当前的用户名；可以使用 
web.Security.FormsAuthentication.RedirectFromLoginPage方法将已验证的用户重定向到用户刚才请求的页面.具体的实例请参考: 

Forms验证 http://www.fanvb.net/websample/dataauth.aspx 

3、＜compilation＞节 

作用：配置 ASP.NET 使用的所有编译设置。默认的debug属性为“True”.在程序编译完成交付使用之后应将其设为True（Web.config文件中有详细说明，此处省略示例） 

4、＜customErrors＞ 

作用：为 ASP.NET 应用程序提供有关自定义错误信息的信息。它不适用于 XML Web services 中发生的错误。 

示例：当发生错误时，将网页跳转到自定义的错误页面。 

＜customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly"＞ 
＜/customErrors＞ 
其中元素defaultRedirect表示自定义的错误网页的名称。mode元素表示：对不在本地 Web 服务器上运行的用户显示自定义(友好的)信息。 

5、＜httpRuntime＞节 

作用：配置 ASP.NET HTTP 运行库设置。该节可以在计算机、站点、应用程序和子目录级别声明。 

示例：控制用户上传文件最大为4M，最长时间为60秒，最多请求数为100 

＜httpRuntime maxRequestLength="4096" executionTimeout="60" appRequestQueueLimit="100"/＞ 
6、 ＜pages＞ 

作用：标识特定于页的配置设置（如是否启用会话状态、视图状态，是否检测用户的输入等）。＜pages＞可以在计算机、站点、应用程序和子目录级别声明。 

示例：不检测用户在浏览器输入的内容中是否存在潜在的危险数据（注：该项默认是检测，如果你使用了不检测，一要对用户的输入进行编码或验证)，在从客户端回发页时将检查加密的视图状态，以验证视图状态是否已在客户端被篡改。(注：该项默认是不验证） 

＜pages buffer="true" enableViewStateMac="true" validateRequest="false"/＞ 
7、＜sessionState＞ 

作用：为当前应用程序配置会话状态设置（如设置是否启用会话状态，会话状态保存位置）。 

示例： 

＜sessionState mode="InProc" cookieless="true" timeout="20"/＞ 
＜/sessionState＞ 
注： 

mode="InProc"表示：在本地储存会话状态（你也可以选择储存在远程服务器或SAL服务器中或不启用会话状态） 

cookieless="true"表示：如果用户浏览器不支持Cookie时启用会话状态(默认为False） 

timeout="20"表示：会话可以处于空闲状态的分钟数 

8、＜trace＞ 

作用：配置 ASP.NET 跟踪服务，主要用来程序测试判断哪里出错。 

示例：以下为Web.config中的默认配置： 

＜trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" /＞ 
注： 

enabled="false"表示不启用跟踪；requestLimit="10"表示指定在服务器上存储的跟踪请求的数目 

pageOutput="false"表示只能通过跟踪实用工具访问跟踪输出； 

traceMode="SortByTime"表示以处理跟踪的顺序来显示跟踪信息 

localOnly="true" 表示跟踪查看器 (trace.axd) 只用于宿主 Web 服务器 

三、自定义Web.config文件配置节 

自定义Web.config文件配置节过程分为两步。 

一是在在配置文件顶部 ＜configSections＞ 和 ＜/configSections＞标记之间声明配置节的名称和处理该节中配置数据的 .NET Framework 类的名称。 

二是在 ＜configSections＞ 区域之后为声明的节做实际的配置设置。 

示例：创建一个节存储数据库连接字符串 

＜configuration＞ 
＜configSections＞ 
＜section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/＞ 
＜/configSections＞ 

＜appSettings＞ 
＜add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/＞ 
＜/appSettings＞ 

＜system.web＞ 
...... 
＜/system.web＞ 
＜/configuration＞ 
四、访问Web.config文件 

你可以通过使用ConfigurationSettings.AppSettings 静态字符串集合来访问 Web.config 文件示例：获取上面例子中建立的连接字符串。 

Dim sconstr As String = ConfigurationSettings.AppSettings("SconStr") 
Dim scon = New SqlConnection(sconstr)

 

 

ASP.NET的高级配置Web.config authorization

 

 

 

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