ASP.NET安全问题－－Forms验证的具体介绍（上篇）

ASP.NET安全问题－－Forms验证的具体介绍（上篇）2011-02-21 Cnblogs 小洋前言：在ASP.NET中，常用的就是Forms验证，最重要的原因就是灵活。因为Forms验证细细的谈起来也确实不少，而且我也不想草草的说完了事，那对大家和自己都不负责任的。

本篇的话题如下：

Forms验证的工作原理

Forms验证中的API

Forms验证的工作原理

我们知道，Forms验证主要是基于cookie的，说白一点就是：把用户信息保存在cookie中，然后发送到客户端；再就是解析客户端的发送了的cookie信息，进行解析，然后进行验证。关于cookieless的工作原理和方法，我这里不赘述，大家可以参看我的另外的一片文章：浅谈ASP.NET内部机制（一）。

当匿名用户请求一个需要验证后才能访问的资源和页面的时候，那么如果采用了Forms验证，那么URL授权模块就会把用户重定向到登录页面。而之前请求的URL就会被保存起来，等到用户正确的登录后，就再次转向之前要请求的页面。我想这点，大家应该都用过。

下面我们就看看登录的时候发生了什么，看看登录的具体的流程？也请大家注意我使用的一些术语，因为这些术语再Forms中都有特定的对象，大家之后就可以看到的，很重要。

1.再浏览器中有个登录窗体，要输入用户名和密码等凭证，通过提交给服务器的ASP.NET网站来审核，检查凭证是否正确。

2.如果凭证正确，那么就会再服务器端就会创建一个"身份验证票据"。身份验证票据中含有了经过加密的用户信息。

3.这个票据再服务器端被写入cookie中，然后发送到客户端。

4.然后用户就被重定向到他们最初请求的URL中。

注：大家可能会有疑问：最初请求的URL到底保存在哪里？不要担心，现在只要明白上面的流程就OK。

5.上面第4步就是要转向最初请求的URL，假设最初的请求页面是Default.aspx,那么现在就是从登录的页面Login.aspx转向到Default.aspx 页面，此时因为身份验证的票据cookie已经存在于客户端的浏览器中了，此时的转向Default.aspx页面时，实际是再次向服务器端发起了请求，所以正如我们之前所谈到的：每个请求都要从ASP.NET管道中一级级的向后传，要经历ASP.NET的的生命周期：Application_BeginRequest,Application_AuthenticateRequest.....。（希望大家明白）

但是这次的请求就和第一次我们发起的请求步同了，为什么？

第一次我们请求Default.aspx页面的时候，我们根本就没有提供任何的表明我们身份的票据，但是这次我们已经登录了，而且我们的浏览器中已经有了我们的身份验证的票据的cookie，此时在Application_AuthenticateRequest事件中，Forms验证模块就获取表明我们身份cookie，然后就利用cookie中信息填充Context.User。

验证模块处理完之后就是授权模块起作用了。其实URL授权模块就会利用我们之前填充在Context.User中的信息来验证用户是否被批准访问所请求的资源或者页面。

Forms验证中的API

实现Forms身份验证之前，我们看看组成Forms验证的API以及相关的类：

FormsAuthenticationModule:对每个请求进行验证的HTTP模块

FormsAuthentication:包含在Forms验证中我们常用的方法和属性（很重要的）

FormsIdentity：Forms验证标识。

FormsAuthenticationTicket：身份验证的票据，对用户的信息进行加密后的产物，我们一般把它写如cookie中，之前我们谈过了的。

上面的类在System.Web.Security下。