Asp.net的身份验证有有三种,分别是"Windows | Forms | Passport",其中又以Forms验证用的最多,也最灵活。
Forms 验证方式对基于用户的验证授权提供了很好的支持,可以通过一个登录页面验证用户的身份,将此用户的身份发回到客户端的Cookie,之后此用户再访问这个web应用就会连同这个身份Cookie一起发送到服务端。服务端上的授权设置就可以根据不同目录对不同用户的访问授权进行控制了。下面大概的看一下Forms的过程。Forms身份验证基本原理:一 身份验证要采用Forms身份验证,先要在应用程序根目录中的Web.config中做相应的设置:<authentication mode="forms"> 
    <forms name=".ASPXAUTH " loginUrl="/login.aspx" timeout="30" path= "/">
    </forms> 
</authentication>其中<authentication mode= "forms"> 表示本应用程序采用Forms验证方式。
1. <forms>标签中的name表示指定要用于身份验证的 HTTP Cookie。默认情况下,name 的值是 .ASPXAUTH。采用此种方式验证用户后,以此用户的信息建立一个FormsAuthenticationTicket类型的身份验证票,再加密序列化为一个字符串,最后将这个字符串写到客户端的name指定名字的Cookie中.一旦这个Cookie写到客户端后,此用户再次访问这个web应用时会将连同Cookie一起发送到服务端,服务端将会知道此用户是已经验证过的. 再看一下身份验证票都包含哪些信息呢,我们看一下FormsAuthenticationTicket类:
CookiePath: 返回发出 Cookie 的路径。注意,窗体的路径设置为 /。由于窗体区分大小写,这是为了防止站点中的 URL 的大小写不一致而采取的一种保护措施。这在刷新 Cookie 时使用
Expiration: 获取 Cookie 过期的日期/时间。
IsPersistent: 如果已发出持久的 Cookie,则返回 true。否则,身份验证 Cookie 将限制在浏览器生命周期范围内。
IssueDate: 获取最初发出 Cookie 的日期/时间。
Name: 获取与身份验证 Cookie 关联的用户名。
UserData :获取存储在 Cookie 中的应用程序定义字符串。
Version: 返回字节版本号供将来使用。
2. <forms>标签中的loginUrl指定如果没有找到任何有效的身份验证 Cookie,为登录将请求重定向到的 URL。默认值为 default.aspx。loginUrl指定的页面就是用来验证用户身份的,一般此页面提供用户输入用户名和密码,用户提交后由程序来根据自己的需要来验证用户的合法性(大多情况是将用户输入信息同数据库中的用户表进行比较),如果验证用户有效,则生成同此用户对应的身份验证票,写到客户端的Cookie,最后将浏览器重定向到用户初试请求的页面.一般是用FormsAuthentication.RedirectFromLoginPage 方法来完成生成身份验证票,写回客户端,浏览器重定向等一系列的动作.public static void RedirectFromLoginPage( string userName, bool createPersistentCookie, string strCookiePath );其中:
userName: 就是此用户的标示,用来标志此用户的唯一标示,不一定要映射到用户账户名称.
createPersistentCookie: 标示是否发出持久的 Cookie。
若不是持久Cookie,Cookie的有效期Expiration属性有当前时间加上web.config中timeout的时间,每次请求页面时,在验证身份过程中,会判断是否过了有效期的一半,要是的话更新一次cookie的有效期;若是持久cookie,Expiration属性无意义,这时身份验证票的有效期有cookie的Expires决定,RedirectFromLoginPage方法给Expires属性设定的是50年有效期。
strCookiePath: 标示将生成的Cookie的写到客户端的路径,身份验证票中保存这个路径是在刷新身份验证票Cookie时使用(这也是生成Cookie的Path),若没有strCookiePath 参数,则使用web.config中 path属性的设置。这里可以看到,此方法参数只有三个,而身份验证票的属性有七个,不足的四个参数是这么来的:
IssueDate: Cookie发出时间由当前时间得出,
Expiration:过期时间由当前时间和下面要说的<forms>标签中timeout参数算出。此参数对非持久性cookie有意义。
UserData: 这个属性可以用应用程序写入一些用户定义的数据,此方法没有用到这个属性,只是简单的将此属性置为空字符串,请注意此属性,在后面我们将要使用到这个属性。
Version: 版本号由系统自动提供.RedirectFromLoginPage方法生成生成身份验证票后,会调用FormsAuthentication.Encrypt 方法,将身份验证票加密为字符串,这个字符串将会是以.ASPXAUTH为名字的一个Cookie的值。这个Cookie的其它属性的生成:Domain,Path属性为确省值,Expires视createPersistentCookie参数而定,若是持久cookie,Expires设为50年以后过期;若是非持久cookie,Expires属性不设置。
生成身份验证Cookie后,将此Cookie加入到Response.Cookies中,等待发送到客户端。
最后RedirectFromLoginPage方法调用FormsAuthentication.GetRedirectUrl 方法获取到用户原先请求的页面,重定向到这个页面。3. <forms>标签中的timeout和path,是提供了身份验证票写入到Cookie过期时间和默认路径。以上就是基于Forms身份验证的过程,它完成了对用户身份的确认。下面介绍基于Forms身份验证的访问授权。二 访问授权验证了身份,是要使用这个身份,根据不同的身份我们可以进行不同的操作,处理,最常见的就是对不同的身份进行不同的授权,Forms验证就提供这样的功能。Forms授权是基于目录的,可以针对某个目录来设置访问权限,比如,这些用户可以访问这个目录,那些用户不能访问这个目录。
同样,授权设置是在你要控制的那个目录下的web.config文件中来设置:
<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>标签表示允许访问,其中的属性
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事件要对用户访问权限就行验证,看此用户或角色是否有权限访问这个页面,之后在这个请求的生命周期内再改变此用户的身份或角色就没有意义了。

解决方案 »

  1.   

    有在IIS中设定什么东东吗?
      

  2.   

    http://chs.gotdotnet.com/quickstart/aspplus/doc/authandauth.aspx
      

  3.   


    <script language="javascript">
    function  showLogin()
    {
    var nDialogWidth=422;
    var nDialogHeight=280;
    var nLeft=(window.screen.availWidth-nDialogWidth)/2;
    var nTop=(window.screen.availHeight-nDialogHeight)/2;
    window.moveTo(-9999,-9999);//窗口最小化
    var sFeatures="dialogLeft:"+nLeft+"px;dialogTop:"+nTop+"px;dialogHeight:"+nDialogHeight+"px;dialogWidth:"+nDialogWidth+"px;help:no;status:no";
    var bLogged=window.showModalDialog("LoginForms/Login.htm",window,sFeatures);

    if (bLogged)
    {
    window.moveTo(0,0);
    window.location="Default.aspx";
    }
    else
    {
    window.close();
    }
    }
    </script>
    login.aspx page_loadSystemFramework.JSUtility.ExecuteBlock(this,"showLogin()");注:SystemFramework.JSUtility.ExecuteBlock是一个调用客户端的js程序用户身份验证通过后
    FormsAuthentication.SetAuthCookie(this.txtUserName.Text,false);是不是cookie没写到客户端?
      

  4.   


    RedirectFromLoginPage 方法,便可自动生成窗体身份验证 Cookie,并将用户重定向到相应的页
      

  5.   

    我想大概是目录的问题,因为我调用的是LoginForms下的LoginForm.aspx
    用户身份验证是在LoginForms\LoginForm.aspx中进行的
    LoginForms目录下的web.config内容如下:
    <configuration>
    <system.web>
    <authorization>
    <allow users="*" />
    </authorization>
    </system.web>
    </configuration>是不是身份认证对根目录无效?
      

  6.   

    cookie在客户端已生成了,可以查到,但还是会重定到login.aspx解释一下我程序是如何做的:根下的web.config
        <authentication mode="Forms">
       <forms loginUrl="Login.aspx"/>
        </authentication>
        <authorization>
    <deny users="?"/> 
        </authorization根下的Login.aspx 显示一个模态对话框,对话框内页面是LoginForms\Login.htm
    Login.htm是一个单框架,框架的页面是LoginForms\LoginForm.aspx
    身份认证是在LoginForms\LoginForm.aspx中做的,客户端的cookie己生成.但认证对根无效,定位到根下的default.aspx时将会重定位到根下的Login.aspx,此种情况如何解决?
      

  7.   

    !!@!@!@!#@!##@!$#@#@$@!#@!#@!#!@#
    晕呀!!!!!!!
    这个问题有点特殊性,主要是认证目录的问题!因为我做的登录界面不是一个页面组成的(loginUrl可以设定多页面吗?)所以在根下有一个LoginForms的子目录,它的web.config设定所有用户均可访问,而我的认证过程是在loginForms下的一个页面上完成的,所以对根下无效!附:
    根下web.config
    <authentication mode="Forms">
        <forms loginUrl="Login.aspx"/>
    </authentication>
    <authorization>
        <deny users="?"/> 
    </authorization>LoginForms子目录下的web.config<authorization>
        <allow users="*" />
    </authorization>登录页面有三个:根下的Login.aspx和子目录下LoginForms下的Login.htm,LoginForm.aspx
    三个页面的关系为:根下的Login.aspx用JS显示一个modal对话框,对话框中的页面文件为LoginForms下的Login.htm,Login.htm为单框架,框架中的页面为LoginForms下的LoginForm.aspx.身份认证代码是在LoginForms目录下的LoginForm.aspx中调用FormsAuthentication.SetAuthCookie完成的,但认证对根无效.注:
    之所以要建一个无需认证的子目录LoginForms,是因为如果根下的Login.aspx调用根下的login.htm的LoginForm.aspx时,会引起重定向Login.aspx,这样就会产生死锁!!!!高手指教,先谢了!