WEB.CONFIG 实现不同文件夹下 FORM验证的访问权限

首先。我们让所有LOGIN之后的页面都继承基页（实现 SESSIOn 验证）。

http://www.cnblogs.com/mahaisong/archive/2011/06/02/2068679.html

其次：我们根据用户类型。来设置权限

  Session["AdminInfo"] = adminModel;//把对象信息放入session中，备用
   //FormsAuthentication.SetAuthCookie(username, false);

//根据用户类型。来设置权限

                                        if (adminModel.UserType == 0) { System.Web.Security.FormsAuthentication.SetAuthCookie("admin", false); }//最高权限
                             if (adminModel.UserType == 1) { System.Web.Security.FormsAuthentication.SetAuthCookie("user", false); }//普通权限
                                        Response.Redirect("../MyOffice.aspx",false);

第三、我们在登录后可访问的文件夹下设置不同用户角色的访问权限（Web.Config.XML）中:

<configuration>
    <appSettings/>
    <connectionStrings/>
    <system.web>
        <authorization>
注意：要对每个用户角色进行限制

            <allow users="admin"/>
            <deny users="user"/>
        </authorization>
    </system.web>
</configuration>

这些问题没有解决： <allow users="admin"/>
            <deny users="*"/>

这样其实没有任何的作用。所有人还是都可以访问

<allow users="admin"/>
            <deny users="？"/>

这样也没有什么作用。所有人都可以访问

<allow>标签表示允许访问，其中的属性
1. users：一个逗号分隔的用户名列表，这些用户名已被授予对资源的访问权限。问号 (?) 允许匿名用户；星号 (*) 允许所有用户。
2. roles：一个逗号分隔的角色列表，这些角色已被授予对资源的访问权限。
3. verbs：一个逗号分隔的 HTTP 传输方法列表，这些 HTTP 传输方法已被授予对资源的访问权限。注册到 ASP.NET 的谓词为 GET、HEAD、POST 和 DEBUG。

<deny>标签表示不允许访问。其中的属性同上面的。

在运行时，授权模块迭代通过 <allow> 和 <deny> 标记，直到它找到适合特定用户的第一个访问规则。

然后，它根据找到的第一项访问规则是 <allow> 还是 <deny> 规则来允许或拒绝对 URL 资源的访问。

Machine.config 文件中的默认身份验证规则是 <allow users="*"/>，因此除非另行配置，否则在默认情况下会允许访问。

那么这些user 和roles又是如何得到的呢？下面看一下授权的详细过程：

1. 一旦一个用户访问这个网站，就行登录确认了身份，身份验证票的cookie也写到了客户端。之后，这个用户再次申请这个web的页面，身份验证票的cookie就会发送到服务端。在服务端，asp.net为每一个http请求都分配一个HttpApplication对象来处理这个请求，在HttpApplication.AuthenticateRequest事件后，安全模块已建立用户标识，就是此用户的身份在web端已经建立起来，这个身份完全是由客户端发送回来的身份验证票的cookie建立的。
2. 用户身份在HttpContext.User 属性中，在页面中可以通过Page.Context 来获取同这个页面相关的HttpContext对象。对于Forms验证，HttpContext.User属性是一个GenericPrincipal类型的对象，GenericPrincipal只有一个公开的属性Identity，有个私有的m_role属性，是string[]类型，存放此用户是属于哪些role的数组，还有一个公开的方法IsInRole(string role)，来判断此用户是否属于某个角色。
由于身份验证票的cookie中根本没有提供role这个属性，就是说Forms身份验证票没有提供此用户的role信息，所以，对于Forms验证，在服务端得到的GenericPrincipal 用户对象的m_role属性永远是空的。
3. GenericPrincipal. Identity 属性是一个FormsIdentity类型的对象，这个对象有个Name属性，就是此用户的标示，访问授权就是将此属性做为user来进行授权验证的。FormsIdentity还有一个属性，就是Ticket属性，此属性是身份验证票FormsAuthenticationTicket类型，就是之前服务器写到客户端的身份验证票。
服务器在获取到身份验证票FormsAuthenticationTicket对象后，查看这个身份验证票是不是非持久的身份验证，是的话要根据web.config中timeout属性设置的有效期来更新这个身份验证票的cookie（为避免危及性能，在经过了超过一半的指定时间后更新该 Cookie。这可能导致精确性上的损失。持久性 Cookie 不超时。）
4. 在HttpApplication.ResolveRequestCache事件之前，asp.net开始取得用户请求的页面，建立HttpHandler控制点。这就意味着，在HttpApplication.ResolveRequestCache事件要对用户访问权限就行验证，看此用户或角色是否有权限访问这个页面，之后在这个请求的生命周期内再改变此用户的身份或角色就没有意义了。

以上是Forms验证的全过程，可以看出，这个Forms验证是基于用户的，没有为角色的验证提供直接支持。身份验证票FormsAuthenticationTicket 中的Name属性是用户标示，其实还有一个属性UserData，这个属性可以由应用程序来写入自定义的一些数据，我们可以利用这个字段来存放role的信息，从而达到基于角色验证的目的。

WEB.CONFIG 实现 不同文件夹下 FORM验证的访问权限

WEB.CONFIG 实现不同文件夹下 FORM验证的访问权限