本文示例代码：http://www.codeplex.com/a/Release/ProjectReleases.aspx?ReleaseId=9518
前言
本来使用Forms Authentication进行用户验证的方式是最常见的，但系统地阐明其方法的文章并不多见，网上更多的文章都是介绍其中某一部分的使用方法或实现原理，而更多的朋友则发文询问如何从头到尾完整第实现用户的注册、登录。因此，Anders Liu在这一系列文章中计划通过一个实际的例子，介绍如何基于Forms Authentication实现：
l 用户注册（包括密码的加密存储）
l 用户登录（包括密码的验证、设置安全Cookie）
l 用户实体替换（使用自己的类型作为HttpContext.User的类型）
有关Forms Authentication的原理等内容不属于本文的讨论范畴，大家可以通过在Google等搜索引擎中输入“Forms Authentication”、“Forms身份验证”、“窗体身份验证”等关键词来查看更多资源。本文仅从实用的角度介绍如何使用这一技术。
不使用Membership
本文介绍的实现方式不依赖ASP.NET 2.0提供的Membership功能。这主要是因为，如果使用Membership，就必须用aspnet_regsql.exe实用工具配置数据库，否则就得自己写自定义的MembershipProvider。
如果用aspnet_regsql.exe配置数据库，就会导致数据库中出现很多我们实际并不需要的表或字段。此外更重要的是，默认的SqlMembershipProvider给很多数据表添加了ApplicationID列，其初衷可能是希望可以将多个应用程序的用户全部放在一个库里，但又能彼此隔离。但实际情况是，每个应用程序都在其自身的数据库中保存用户数据。因此，引入这个ApplicationID无端地在每次查找用户时增加了额外的条件。
另一方面，如果考虑自己实现一个MembershipProvider，因为工作量巨大，有点得不偿失。
但是，如果不使用Membership，也就无法享受ASP.NET 2.0中新增的Login等控件的便利了。
与Forms Authentication相关的配置
在web.config文件中，<system.web>/<authentication>配置节用于对验证进行配置。为<authentication>节点提供mode="Forms"属性可以启用Forms Authentication。一个典型的<authentication>配置节如下所示：
<authentication mode="Forms">
<forms
name=".ASPXAUTH"
loginUrl="login.aspx"
defaultUrl="default.aspx"
protection="All"
timeout="30"
path="/"
requireSSL="false"
slidingExpiration="false"
enableCrossAppRedirects="false"
cookieless="UseDeviceProfile"
domain=""
/>
</authentication>
以上代码使用的均是默认设置，换言之，如果你的哪项配置属性与上述代码一致，则可以省略该属性例如<forms name="MyAppAuth" />。下面依次介绍一下各种属性：
l name——Cookie的名字。Forms Authentication可能会在验证后将用户凭证放在Cookie中，name属性决定了该Cookie的名字。通过FormsAuthentication.FormsCookieName属性可以得到该配置值（稍后介绍FromsAuthentication类）。
l loginUrl——登录页的URL。通过FormsAuthentication.LoginUrl属性可以得到该配置值。当调用FormsAuthentication.RedirectToLoginPage()方法时，客户端请求将被重定向到该属性所指定的页面。loginUrl的默认值为“login.aspx”，这表明即便不提供该属性值，ASP.NET也会尝试到站点根目录下寻找名为login.aspx的页面。
l defaultUrl——默认页的URL。通过FormsAuthentication.DefaultUrl属性得到该配置值。
l protection——Cookie的保护模式，可取值包括All（同时进行加密和数据验证）、Encryption（仅加密）、Validation（仅进行数据验证）和None。为了安全，该属性通常从不设置为None。
l timeout——Cookie的过期时间。
l path——Cookie的路径。可以通过FormsAuthentication.FormsCookiePath属性得到该配置值。
l requireSSL——在进行Forms Authentication时，与服务器交互是否要求使用SSL。可以通过FormsAuthentication.RequireSSL属性得到该配置值。
l slidingExpiration——是否启用“弹性过期时间”，如果该属性设置为false，从首次验证之后过timeout时间后Cookie即过期；如果该属性为true，则从上次请求该开始过timeout时间才过期，这意味着，在首次验证后，如果保证每timeout时间内至少发送一个请求，则Cookie将永远不会过期。通过FormsAuthentication.SlidingExpiration属性可以得到该配置值。
l enableCrossAppRedirects——是否可以将以进行了身份验证的用户重定向到其他应用程序中。通过FormsAuthentication.EnableCrossAppRedirects属性可以得到该配置值。为了安全考虑，通常总是将该属性设置为false。
l cookieless——定义是否使用Cookie以及Cookie的行为。Forms Authentication可以采用两种方式在会话中保存用户凭据信息，一种是使用Cookie，即将用户凭据记录到Cookie中，每次发送请求时浏览器都会将该Cookie提供给服务器。另一种方式是使用URI，即将用户凭据当作URL中额外的查询字符串传递给服务器。该属性有四种取值——UseCookies（无论何时都使用Cookie）、UseUri（从不使用Cookie，仅使用URI）、AutoDetect（检测设备和浏览器，只有当设备支持Cookie并且在浏览器中启用了Cookie时才使用Cookie）和UseDeviceProfile（只检测设备，只要设备支持Cookie不管浏览器是否支持，都是用Cookie）。通过FormsAuthentication.CookieMode属性可以得到该配置值。通过FormsAuthentication.CookiesSupported属性可以得到对于当前请求是否使用Cookie传递用户凭证。
l domain——Cookie的域。通过FormsAuthentication.CookieDomain属性可以得到该配置值。
以上针对<system.web>/<authentication>/<forms>节点的介绍非常简略，基本上是Anders Liu个人对于文档进行的额外说明。有关<forms>节点的更多说明，请参见MSDN文档（http://msdn2.microsoft.com/zh-cn/library/1d3t3c61(VS.85).aspx）。
FormsAuthentication类
FormsAuthentication类用于辅助我们完成窗体验证，并进一步完成用户登录等功能。该类位于system.web.dll程序集的System.Web.Security命名空间中。通常在Web站点项目中可以直接使用这个类，如果是在类库项目中使用这个类，请确保引用了system.web.dll。
前一节已经介绍了FormsAuthentication类的所有属性。这一节将介绍该类少数几个常用的方法。
RedirectToLoginPage方法用于从任何页面重定向到登录页，该方法有两种重载方式：
public static void RedirectToLoginPage ()
public static void RedirectToLoginPage (string extraQueryString)
两种方式均会使浏览器重定向到登录页（登录页的URL由<forms>节点的loginUrl属性指出）。第二种重载方式还能够提供额外的查询字符串。
RedirectToLoginPage通常在任何非登录页的页面中调用。该方法除了进行重定向之外，还会向URL中附加一个ReturnUrl参数，该参数即为调用该方法时所在的页面的URL地址。这是为了方便登录后能够自动回到登录前所在的页面。
RedirectFromLoginPage方法用于从登录页跳转回登录前页面。这个“登录前”页面即由访问登录页时提供的ReturnUrl参数指定。如果没有提供ReturnUrl参数（例如，不是使用RedirectToLoginPage方法而是用其他手段重定向到或直接访问登录页时），则该方法会自动跳转到由<forms>节点的defaultUrl属性所指定的默认页。
此外，如果<forms>节点的enableCrossAppRedirects属性被设置为false，ReturnUrl参数所指定的路径必须是当前Web应用程序中的路径，否则（如提供其他站点下的路径）也将返回到默认页。
RedirectFromLoginPage方法有两种重载形式：
public static void RedirectFromLoginPage (string userName, bool createPersistentCookie)
public static void RedirectFromLoginPage (string userName, bool createPersistentCookie, string strCookiePath)
userName参数表示用户的标识（如用户名、用户ID等）；createPersistentCookie参数表示是否“记住我”；strCookiePath参数表示Cookie路径。
RedirectFromLoginPage方法除了完成重定向之外，还会将经过加密（是否加密取决于<forms>节点的protection属性）的用户凭据存放到Cookie或Uri中。在后续访问中，只要Cookie没有过期，则将可以通过HttpContext.User.Identity.Name属性得到这里传入的userName属性。
此外，FormsAuthentication还有一个SignOut方法，用于完成用户注销。其原理是从Cookie或Uri中移除用户凭据。
小结
好了，至此所需要掌握的基础知识就齐备了，接下来我们将实现用户注册、登录等功能。
从这一部分开始，我们将通过一个实际的完整示例来看一下如何实现用户注册与登录。在介绍注册与登录之前，我们首先介绍一下如何判断用户是否已登录，并未后面的示例编写一些基础代码。
判断用户是否已经登录
首先，在Web站点项目中添加一个MasterPage，例如MasterPage.master。在这个母版页的ContentPlaceHolder控件之前、<From>标签之内插入如下代码：
<asp:Panel ID="pnlAnonymous" runat="server">
<asp:LinkButton ID="btnLogin" runat="server" Text="登录" OnClick="btnLogin_Click"></asp:LinkButton> |
<asp:HyperLink ID="lnkRegister" runat="server" NavigateUrl="~/register.aspx" Text="注册"></asp:HyperLink>
</asp:Panel>
<asp:Panel ID="pnlLoggedin" runat="server">
欢迎您，<asp:Label ID="lblUserName" runat="server"></asp:Label>！
[<asp:LinkButton ID="btnLogout" runat="server" Text="注销"
onclick="btnLogout_Click"></asp:LinkButton>]
</asp:Panel>
<asp:Panel ID="pnlNavigate" runat="server">
<asp:HyperLink ID="lnkDefault" runat="server" NavigateUrl="~/default.aspx" Text="首页"></asp:HyperLink> |
<asp:HyperLink ID="lnkTest" runat="server" NavigateUrl="~/test.aspx" Text="测试页"></asp:HyperLink>
</asp:Panel>
这里提供了三个Panel控件——pnlAnonymous、pnlLoggedin和pnlNavigate。pnlAnonymous用于在用户未登录时显示“登录”和“注册”链接；pnlLoggedin用于在用户已登录时显示用户信息（如用户名和到用户个人信息页的链接等，这里仅显示用户名），以及一个“注销”按钮；pnlNavigate在任何时候都显示，是站点的导航栏。
现在我们要实现的是，判断用户是否登录，并显示pnlAnonymous和pnlLoggedin二者之一。这里，如果是使用ASP.NET 2.0 Membership，则可以方便地使用LoginView、LoginName和LoginStatus等控件实现这些功能；然而我们不得不为此忍受Membership所带来的庞大而繁多的数据库对象，或者花更多时间去编写自定义的MembershipPorvider。
这一系列的第一部分曾介绍过，如果用户已经登录，则可以从HttpContext.User.Identity.Name得到已登录用户的标识（通常是用户名）。然而，如果用户未登录，这个值则为空字符串。因此，通过判断该值是否为空字符串，即可的值用户是否已登录。
由此，我们在MasterPage的后台代码中添加Page_Init方法，在页面初始化时判断用户是否登录，并显示对应的Panel控件；此外，在用户已登录时，在pnlLoggedin中的欢迎语里插入已登录用户的用户名。
protected void Page_Init(object sender, EventArgs e)
{
// 判断用户是否已登录。
if(HttpContext.Current.User.Identity.Name == "")
{
// 用户未登录。
pnlAnonymous.Visible = true;
pnlLoggedin.Visible = false;
}
else
{
// 用户已登录。
pnlAnonymous.Visible = false;
pnlLoggedin.Visible = true;
lblUserName.Text = HttpContext.Current.User.Identity.Name;
}
}
此外，我们还向项目中添加了default.aspx、login.aspx、register.aspx、test.aspx这样四个页面。其中test.aspx用于检验重定向到登录页后的ReturnUrl参数值，和登录后回到之前页面的效果。
用户注册
用户注册部分并不属于验证的范畴，因此Forms Authentication也没有提供过多的支持。然而用户注册是比较简单的，只需通过一个页面搜集用户信息，并存放到数据库中即可。在这个示例中，为了方便和突出真正要讨论的内容，用户信息并不是真的放到数据库中的，而是放在一个集合里，不过通过一个DataAccess类来隐藏这种差异。理论上，一旦关闭应用程序并重新开启，放在集合中的数据就会丢失。然而实际上，再重复运行这里的示例时，用户数据并不会丢失，即便应用程序有所改动也是。这是因为ASP.NET 2.0对于Web项目都是动态重新编译的，应用程序从未直接终止过。
此外，就用户的数据实体类而言，我们仅提供了注册、登录所必需的属性——用户名、密码散列值、密码Salt值。（关于密码的加Salt值散列，请参见之前的一篇短文。）
为了进行用户注册，我们建立了register.aspx页面，该页面仅负责搜集用户信息，真正的创建用户动作在App_Code下的Membership类中完成。注意，此Membership非彼Membership，与ASP.NET 2.0 Membership没有任何关系。
首先在Membership类中添加一个静态方法CreateUser，用于创建用户。该方法完成用户实体的创建和密码的散列等功能。其代码如下所示：
public static void CreateUser(string userName, string password)
{
UserObject user = new UserObject();
user.Name = userName;
user.PasswordSalt = GenerateSalt();
user.PasswordHash = EncodePassword(password, user.PasswordSalt);
DataAccess.AddUser(user);
}
这段代码非常简单，其中用到了GenerateSalt和EncodePassword方法，这两个方法用于完成salt值的生成和密码的加salt散列。其代码抽取自MembershipProvider类，进行了精简如下所示：
public const string PasswordHashAlgorithmName = "SHA1";
static string EncodePassword(string password, string salt)
{
byte[] src = Encoding.Unicode.GetBytes(password);
byte[] saltbuf = Convert.FromBase64String(salt);
byte[] dst = new byte[saltbuf.Length + src.Length];
byte[] inArray = null;
Buffer.BlockCopy(saltbuf, 0, dst, 0, saltbuf.Length);
Buffer.BlockCopy(src, 0, dst, saltbuf.Length, src.Length);
HashAlgorithm algorithm = HashAlgorithm.Create(PasswordHashAlgorithmName);
inArray = algorithm.ComputeHash(dst);
return Convert.ToBase64String(inArray);
}
static string GenerateSalt()
{
byte[] data = new byte[0x10];
new RNGCryptoServiceProvider().GetBytes(data);
return Convert.ToBase64String(data);
}
然后在register.aspx页面中创建搜集用户信息的表单，这个表单非常简单，仅需在ContentPlaceHolder1内添加如下代码：
<table>
<tr><td>用户名：</td><td><asp:TextBox ID="txtUserName" runat="server"></asp:TextBox></td></tr>
<tr><td>密码：</td><td><asp:TextBox ID="txtPassword" runat="server" TextMode="Password"></asp:TextBox></td></tr>
<tr><td colspan="2"><asp:Button ID="btnOK" runat="server" Text="确定"
onclick="btnOK_Click" /></td></tr>
</table>
<asp:Label ID="lblMessage" runat="server"></asp:Label>
注意这比实际的注册页要简单许多，没有对用户名和密码的格式做验证，也没有让用户重复输入密码以确保没有键入错误。但Anders Liu相信，对于聪明的读者而言这些都不是问题，所以不再赘述。
在“确定”按钮的事件处理器中添加如下代码，完成注册功能：
protected void btnOK_Click(object sender, EventArgs e)
{
try
{
Membership.CreateUser(txtUserName.Text, txtPassword.Text);
lblMessage.Text = "用户创建成功！";
}
catch(Exception ex)
{
lblMessage.Text = "错误：" + ex.Message;
}
}
用户登录
用户登录大致由下面几个步骤完成：
l 根据用户名取得与用户相关的信息（用户实体对象）；
l 判断用户密码是否正确；
l 设置用户凭据Cookie并重定向到登录前页面。
我们主要还是在Membership类中来完成这些工作。为Membership类添加一个Login方法：
public static void Login(string userName, string password, bool rememberMe)
{
// 获取用户。
UserObject user = DataAccess.GetUserByName(userName);
if(user == null)
throw new ArgumentException("用户不存在！", "UserName");
// 检查密码是否正确。
string pwdHash = EncodePassword(password, user.PasswordSalt);
if(pwdHash != user.PasswordHash)
throw new ArgumentException("密码错误！", "Password");
// 设置安全Cookie并进行重定向。
FormsAuthentication.RedirectFromLoginPage(userName, rememberMe);
}
这里重点在于检查密码，不过其工作方式已经在上一篇文章中介绍过了，此处不再赘述。读者应该注意到，对密码进行散列使用的是已经存放在数据实体中的Salt值，而不是重新生成Salt值。
这段示例代码通过抛异常来返回错误信息。读者在实际编写这个方法时，可以创建多个Exception类的派生类，分别表示不同的错误；或者采取其他无需抛异常的方式。这一点仁者见仁，智者见智。
接下来，提供一个简单的登录页，完成收集用户名和密码的工作。login.aspx页面的结构也很简单，只需在<ContentPlaceHolder1>中添加下列代码：
<table>
<tr><td>用户名：</td><td><asp:TextBox ID="txtUserName" runat="server"></asp:TextBox></td></tr>
<tr><td>密码：</td><td><asp:TextBox ID="txtPassword" runat="server" TextMode="Password"></asp:TextBox></td></tr>
<tr><td colspan="2">
<asp:Button ID="btnLogin" runat="server" Text="登录" onclick="btnLogin_Click" />
<asp:CheckBox ID="chkRememberMe" runat="server" Text="记住我" />
</td></tr>
</table>
<asp:Label ID="lblMessage" runat="server"></asp:Label>
最后，在“登录”按钮的事件处理器中添加如下代码，调用刚刚写好的Membership.Login方法，完成登录。
protected void btnLogin_Click(object sender, EventArgs e)
{
try
{
Membership.Login(txtUserName.Text, txtPassword.Text, chkRememberMe.Checked);
}
catch(Exception ex)
{
lblMessage.Text = "错误：" + ex.Message;
}
}
至此，用户登录功能就OK了。由于之前已经完成了判断用户是否登录的代码，现在就可以运行示例，注册一个用户并尝试从各个页面进入登录页进行登录了。
用户注销
至此，我们已经为用户进入我们的系统提供了宽敞大路；但作为一个负责任的程序，我们还得确保当用户离开我们的程序时，能够“挥一挥衣袖”不留下一丝痕迹。这个安全离开的行为，我们称之为“注销”；要抹去的“痕迹”也就是登录时留下的用户凭据Cookie。
本文的第一部分已经介绍过，FormsAuthentication.SignOut方法可以协助完成这一任务。我们在MasterPage中也预先放置好了一个“注销”链接按钮，在这里，只要为该按钮添加如下事件处理器即可：
protected void btnLogout_Click(object sender, EventArgs e)
{
FormsAuthentication.SignOut();
Response.Redirect(Request.RawUrl);
}
在这里，首先通过调用FormsAuthentication.SignOut方法移除了用户凭证Cookie。这个方法并不能自动完成跳转，因此我么必须自己完成跳转任务。关于注销后跳转到哪个页面，每个应用程序都有自己的方式（如跳到登录页或跳到首页等），这里选择的是刷新当前页。
小结
好了，到现在为止，完整的用户注册、登录功能就都实现了。由于有了FormsAuthentication类，这一任务已经非常简单了。这一部分仅仅是从实践的角度顺序操作了一下。
下一部分将介绍如何将我们自己的用户实体放到HttpContext.User属性中。
IPrincipal和IIdentity
通过查阅文档，我们可以看到HttpContext.User属性的类型是IPrincipal接口。然而我们知道，接口通常是不能直接访问的，其背后必定隐藏了一个实现了该接口的对象。那么这个实际对象的类型是什么呢？
让我们在前面示例的MasterPage的Page_Init方法上加一个断点，再次运行程序，可以得到HttpContext.User属性的真正类型是System.Security.Principal.GenericPrincipal。
查看IPrincipal接口的定义，可以看到它只有一个公开属性——Identity，其类型是这里要提到的另外一个重要接口IIdentity。通过上面的断点跟踪，我们还能知道对于GenericPrincipal而言，其Identity属性的实际类型是GenericIdentity，也是位于System.Security.Principal命名空间中。
由此，我们引出了.NET Framework中关于Principal（实体）的整个类型系统。所有这些类型都位于mscorlib.dll程序集中，由此也可以看出，这套模型隶属于整个系统的基石。
实现自己的IPrincipal
要想用自己的实体对象替换HttpContext.User，就必须让自己的实体对象实现IPrincipal接口；通常还必须伴随着实现IIdentity接口。
目前系统中有的是一个数据实体对象。一般而言，实现IPrincipal接口有一下两种方式——
l 编写单独的类型实现IPrincipal接口，并在其中包含数据实体对象；
l 修改数据实体对象使其实现IPrincipal接口。
对于这两种方式而言，其Identity属性可以通过以下三种方式实现——
l 使用.NET Framework提供的GenericIdentity；
l 创建自定义的类，实现Identity接口；
l 修改数据实体对象或自定义的实体类，让它们同时实现IPrincipal和IIdentity接口。
对于简单的应用程序而言，通常可以修改数据实体对象，使其同时实现IPrincipal和IIdentity接口。而就复杂的分层架构应用程序，则建议在逻辑层创建分别实现了IPrincipal和IIdentity接口的对象。本文的示例 明显属于前一种情况，因此我们考虑修改作为数据实体类的UserObject类，让其实现两个接口。以下是修改完毕的UserObject类：
public class UserObject : IPrincipal, IIdentity
{
/// <summary>
/// 用户名。
/// </summary>
public string Name;
/// <summary>
/// 密码散列值。
/// </summary>
public string PasswordHash;
/// <summary>
/// 密码salt值。
/// </summary>
public string PasswordSalt;
#region IIdentity Members
public string AuthenticationType
{
get
{
return "Froms";
}
}
public bool IsAuthenticated
{
get
{
return true;
}
}
string IIdentity.Name
{
get
{
return this.Name;
}
}
#endregion
#region IPrincipal Members
public IIdentity Identity
{
get
{
return this;
}
}
public bool IsInRole(string role)
{
return false;
}
#endregion
}
首先我们来看一下对IIdentity接口的实现。该接口要求三个属性——AuthenticationType、IsAuthenticated和Name。AuthenticationType表示该用户标识所使用的验证类型，这里返回的是“Forms”；IsAuthenticated属性表示当前用户是否已经通过验证（即是否已登录。在这个例子里，我们只针对已登录用户进行实体替换，所以这个属性总是返回true。通常，实际的Web应用程序编写时还有一种习惯，就是为未登录用户（称之为匿名用户）也提供一个用户实体对象，此时就需要为IsAuthenticated提供逻辑，判断用户是否已通过验证了。最后IIdentity接口还要求对象提供一个Name属性，在这里，由于已经存在了Name字段，因此才用“显示接口实现”来提供Name属性，返回对象自身的Name字段即可。
接下来我们看一下IPrincipal接口的实现。该接口要求提供一个Identity属性和一个IsInRole方法。由于UserObject类本身已经实现了IIdentity接口，因此在Identity属性中直接reutren this即可。因为我们这个示例不涉及用户分组（角色）方面的技术，因此IsInRole方法总是返回false。
用户实体替换
用户实体替换即使用我们自己编写的类型的实例来替换HttpContext.User属性。实体替换应该发生在HttpApplication的PostAuthenticateRequest事件发生时，因为此时ASP.NET已经从客户端得到了用户凭证Cookie并进行了解密和校验。
我们既可以编写一个HttpModule来处理PostAuthenticateRequest事件，也可以在Global..asax文件中添加时间处理器。这里为了简单，我们选择在Global.asax中添加如下事件处理器：
void Application_PostAuthenticateRequest(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
if(app.Context.User.Identity.Name != "") // 仅在已登录时替换
{
UserObject user = DataAccess.GetUserByName(app.Context.User.Identity.Name);
app.Context.User = user;
Thread.CurrentPrincipal = user;
}
}
在这里我们首先进行了判断，如果用户已登录，才进行实体替换。当然你也可以选择未未登录用户也提供一个匿名用户实体。
接下来，我们通过本来已经存放在HttpContext.User.Identity中的用户标识得到了数据实体对象，然后分别将其赋予HttpContext.User和Thread.CurrentPrincipal。
至此，我们的示例代码就完工了。没有提到的是，完成了这一步之后，你就可以通过类似下面的代码在任何可以访问到HttpContext的地方获取用户实体了：
UserObject user = HttpContext.Current.User as UserObject;
if(user != null)
{
// 可以使用user
}
else
{
// 用户未登录
}
需要注意，由于在这里我们仅对已登录用户进行了用户实体替换，所以代码使用as进行类型转换并结合if语句进行判断是必需的。