最简单的Forms验证实现方法:
FormsAuthentication.SetAuthCookie()方法,传递一个登录名即可
FormsAuthentication.SignOut()方法退出
Forms验证可以保护受限制的页面比如有些页面未登录不能访问或者有的人没有权限访问
这些东西在web.Config中都可以配置
比如 有一个名字为MyInfo.aspx的页面要求这个页面的访问者必须为已经登陆的用户
可以这样子配置
<location path=”MyInfo.aspx”>
<system.web>
<authorization>
<deny users=”?”/>
</authorization>
</system.web>
</location>
但是这样子写如果页面多的话会导致代码过于冗杂,所以可以在代码设计初期,把有相同权限的功能模块
放在一起,所以forms验证可以在Web.config中可以配置一个目录,将多个页面放在同一个目录里,
<location path=”Admin”>
<system.web>
<authorization>
<allow roles=”Admin”/>
<deny users=”*”/>
</authorization>
</system.web>
</location>
需要注意的是 allow和deny的顺序不能写错了,UrlAuthorizationModule将按照这个顺序依次判断的
如果这个页面只能某一类人访问,则需要在最后一条规则设置 <deny users=”*”/>
同样的我们可以在allow和deny中指定多个用户,使用user,deny属性时记得要用逗号分隔开用户的列表,
问号?表示的匿名用户(不需要),星号*表示的所有用户
froms的身份验证是通过cookie来维持的,而且他的cookie是加密的AuthenticateRequest事件一般在global.asax文件中,当一个用户进行身份验证的时候,HttpApplication对象就会触发
AuthenticateRequest事件,也就是意味着每次对应用程序进行页面请求的时候都会触发这个事件,实际上是调用相应的身份验证
模块来处理身份验证的,对于Forms而言,即使从加密的cookie中提取用户的信息并存到Identity和IPicioal
AuthorizeRequest 事件是在AuthenticateRequest事件中通过了身份验证的时候才会触发的,AhtorizeRequest事件调用相应的授权模块来检查用户是否被授权访问他们的请求资源
在ASP.NET中内置的授权模块主要有两个:FileAuthorizationModule和UrlAuthorizationModule。他们也实现了IHttpModule接口。这些模块可以参照所试用的身份验证类型来决定到底采用哪个授权模块:
如果试用的是Windows身份验证,那么在授权检查的时候就会使用FileAuthorizationModule;
如果在web.config中提供了<authorization/>元素,那么就会采用UrlAuthorizationModule。如下面的: <authorization>
<allow roles =”” users=””/>
<deny users=””/>
</authorization> 1.再浏览器中有个登录窗体,要输入用户名和密码等凭证,通过提交给服务器的ASP.NET网站来审核,检查凭证是否正确。
2.如果凭证正确,那么就会再服务器端就会创建一个”身份验证票据”。身份验证票据中含有了经过加密的用户信息。
3.这个票据再服务器端被写入cookie中,然后发送到客户端。
4.然后用户就被重定向到他们最初请求的URL中。 Forms验证中的API
实现Forms身份验证之前,我们看看组成Forms验证的API以及相关的类:
FormsAuthenticationModule:对每个请求进行验证的HTTP模块(实际上就是解析cookie中的加密信息的然后构造一个GenericPrincipal的类实例填充Context.User,并且也创建一个FormsIdentity的实例,FormsAuthenticationModule是一个HTTP模块;)
FormsAuthentication:包含在Forms验证中我们常用的方法和属性(很重要的,FormsAuthenticate是一个类,它有很多的方法和属性)
FormsIdentity:Forms验证标识。
FormsAuthenticationTicket:身份验证的票据,对用户的信息进行加密后的产物,我们一般把它写如cookie中,之前我们谈过了的。
上面的类在System.Web.Security下。 特别注意的就是FormsAuthenticate的Authenticate方法 一般在登录窗体中提交用户信息,然后服务器端验证提交的信息,我们在服务器端常常是去数据库中检查这些信息的正确性,但是去数据库或者其他的数据存储(如文件,活动目录)中去检查只是一种情况。
还有另外的情况。不知道大家是否记得web.config 中的一个配置的节点:
<authentication mode=”Forms”>
<forms>
<credentials>
<user name=”xiaoyang” password=”xiaoyang”/>
<user name=”panyan” password=”panyan”/>
</credentials>
</forms>
</authentication> 如果我们在配置文件配置了上述的信息,那么我们就可以用Authenticate方法来检查提供了用户信息(用户名和密码)是否正确,如果我们没有在web.config配置用户的信息,也就是说我们是把信息保存在数据库等其他的地方,那么我们就不能Authenticate这个方法。当然我们很少用Authenticate这个方法,因为我们不可能把所有用户信息硬编码到配置文件中,但是还是要清楚这个方法。 在FormsAuthenticate中使用频繁的是RedirectFromLoginPage方法。每当验证了用户的凭证后就会使用到这个方法,也就是我们之前说过的:跳转到我们最初请求的页面。
这个方法就这么简单的一”跳”,但是其实在内部做了很多的事情:
1.为用户创建一个身份验证的票据
2.对身份验证的票据进行加密
3.创建一个cookie,把加密的票据保存在cookie中
4.向HTTP响应添加cookie,并且发送给客户端。
5.跳转,并且把用户重定向到最初请求的页面 FormsAuthenticate中涉及到客户端保存cookie的两个属性就是:
FormsCookieName:获取或者设设置cookie的名称
FormsCookiePath:获取或者设置cookie的url路径
其中FormsCookiePath属性有一点要注意:大多数的浏览器会在判断cookie是否要和请求一起发送时,用到cookie路径。(我们一般在配置文件配置path=”/”),如果我们配置的path不是”/”,那么这个cookie就不会和请求发送到服务器端.
FormsAuthenticate中和cookie操作相关的方法有:
Decrypt:提取身份验证cookie的加密信息,创建FormsAuthenticationTicket,也就是解密。
Encrypt:加密。从FormsAuthenticationTicket中获取信息,并且加密。以备我们之后把加密的信息写入cookie
GetAuthCookie:创建身份验证cookie,但是并不把它立即添加到HTTP响应中
SetAuthCookie:创建身份验证cookie,并且把它添加到Response.Cookie中。
RenewTicketIfOld:刷新身份验证cookie的生命周期 GetRedirectUrl:把用户重定向到他们最初请求的页面。
SignOut:使得当前的身份验证cookie过期。我们常用的注销功能。 我们只要在 web.config文件中配置如下就行了:<authentication mode=”Forms”/> 还有一点要特别注意:<authentication/>元素节点只能在应用程序的根文件夹中的 web.config中配置。如果在子文件夹中使用这个节点就会报错。这也说明了每个应用程序只能定义一个身份验证类型。
而且在<authentication/>节点中,我们还可以进行更多的设置。如下:
<authentication mode=”Forms “>
<forms name=”MyCookie”
loginUrl=”Login.aspx”
timeout=”60″
path=”/”
protection=”All”>
</forms>
</authentication>我们下面就看看<forms>节点中的属性的含义和用途:
name:定义身份验证cookie的名称。因为我们把身份验证的票据是存放在cookie中的,而且我们必须给身份验证cookie取具有唯一性的名称,防止和其他的应用程序中的cookie冲突。
loginUrl:从英文名字就可以知道是关于登录的。实际上就是标明把用户重定向到哪个页面取登录。
timeout:设置身份验证cookie持续的时间,以分钟为单位的。而且这个时间是一个相对的时间,就是说每次对用户进行验证时,cookie的期限就会被重新设置。如果在60分钟内用户再没有向服务器发起请求,那么cookie就过期,之后如果用户再次发起请求,那么就要重新输入用户名和密码等信息。
path:设置cookie的保存的路径,一般是设置为”/”,我们不要轻易的改变。
我们之前也说过,我们的身份验证的票据是加密以后再存放如cookie中的,然后再把cookie发送到客户端。当客户端再次请求的时候,再服务器端就会解析客户端发送来的cookie信息,我们必须要确认:客户端发送来的cookie信息就是我们之前从服务器端发送过去的,也就是说,我们要判断,我们的cookie在客户端是否被篡改了。
所以,这就是<forms/>中属性protection的用途。protection的值有四个:
Encryption:对cookie的内容信息进行加密。
Validation:向cookie中的内容添加MAC(消息验证代码),以便服务器判断cookie是否被篡改了。
None:禁用加密和篡改检查
All:同时启用加密和篡改检查。
默认情况下是”All”,因为它可以把数据加密放入cookie中,而且对返回到服务器端的cookie进行验证。