起飞

使用Forms Authentication实现用户注册、登录

前言
　　本来使用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>/配置节用于对验证进行配置。为节点提供mode="Forms"属性可以启用Forms Authentication。一个典型的配置节如下所示： 　　以上代码使用的均是默认设置，换言之，如果你的哪项配置属性与上述代码一致，则可以省略该属性例如。下面依次介绍一下各种属性：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>//节点的介绍非常简略，基本上是Anders Liu个人对于文档进行的额外说明。有关节点的更多说明，请参见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由节点的loginUrl属性指出）。第二种重载方式还能够提供额外的查询字符串。　　RedirectToLoginPage通常在任何非登录页的页面中调用。该方法除了进行重定向之外，还会向URL中附加一个ReturnUrl参数，该参数即为调用该方法时所在的页面的URL地址。这是为了方便登录后能够自动回到登录前所在的页面。　　RedirectFromLoginPage方法用于从登录页跳转回登录前页面。这个“登录前”页面即由访问登录页时提供的ReturnUrl参数指定。如果没有提供ReturnUrl参数（例如，不是使用RedirectToLoginPage方法而是用其他手段重定向到或直接访问登录页时），则该方法会自动跳转到由节点的defaultUrl属性所指定的默认页。　　此外，如果节点的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方法除了完成重定向之外，还会将经过加密（是否加密取决于节点的protection属性）的用户凭据存放到Cookie或Uri中。在后续访问中，只要Cookie没有过期，则将可以通过HttpContext.User.Identity.Name属性得到这里传入的userName属性。　　此外，FormsAuthentication还有一个SignOut方法，用于完成用户注销。其原理是从Cookie或Uri中移除用户凭据。

.net中的认证(authentication)与授权(authorization)

“认证”与“授权”是几乎所有系统中都会涉及的概念，通俗点讲：
　　1、认证(authentication) 就是 “判断用户有没有登录?”，好比windows系统，没登录就无法使用(不管你是用Administrator或Guest用户，总之要先正确登录后，才能进入系统)。
　　2、授权(authorization) 就是"用户登录后的身份/角色识别"，好比"管理员用户"登录windows后，能安装软件、修改windows设置等所有操作，而Guest用户登录后，只有做有限的操作(比如安装软件就被禁止了)。
　　 .net中与"认证"对应的是IIdentity接口，而与"授权"对应的则是IPrincipal接口，这二个接口的定义均在命名空间System.Security.Principal中：

using System;
using System.Runtime.InteropServices;

namespace System.Security.Principal
{
[ComVisible(true)]
public interface IIdentity
{
string AuthenticationType { get; }
bool IsAuthenticated { get; }
string Name { get; }
}
}

using System;
using System.Runtime.InteropServices;

namespace System.Security.Principal
{
[ComVisible(true)]
public interface IPrincipal
{
IIdentity Identity { get; }
bool IsInRole(string role);
}
}

应该注意到：IPrincipal接口中包含着一个只读的IIdentity，这也跟最开始提到的概念一致：识别身份的前提是先登录，只有登录成功后能进一步确认身份。
　　用Membership/Role做过asp.net开发的朋友们，看到这二个接口的定义，应该会觉得很眼熟，想想我们在Asp.Net页面中是如何判断用户是否登录以及角色的？

protected void Page_Load(object sender, EventArgs e)
{
HttpContext ctx = HttpContext.Current;
if (ctx.User.Identity.IsAuthenticated && ctx.User.IsInRole(“管理员”))
{
//管理员该做的事，就写在这里
}
else
{
//Hi，您不是管理员，别胡来!
}
}

这段代码再熟悉不过了，没错！membership/role的原理就是基于这二个接口的，如果再对HttpContext.Current.User刨根问底，能发现下面的定义：

HTTP Basic Authentication认证

前言
大家在登录网站的时候，大部分时候是通过一个表单提交登录信息。
但是有时候浏览器会弹出一个登录验证的对话框，如下图，这就是使用HTTP基本认证。

一、说明 HTTP Basic Authentication
在你访问一个需要HTTP Basic Authentication的URL的时候，如果你没有提供用户名和密码，服务器就会返回401，如果你直接在浏览器中打开，浏览器会提示你输入用户名和密码，也就是上面的图示。
要在发送请求的时候添加HTTP Basic Authentication认证信息到请求中，有两种方法：
一是在请求头中添加Authorization： Authorization: “Basic 用户名和密码的base64加密字符串” 。
二是在url中添加用户名和密码。

二、认证过程：
第一步: 客户端发送http request 给服务器,服务器验证该用户是否已经登录验证过了，如果没有的话，服务器会返回一个401 Unauthozied给客户端，并且在Response 的 header “WWW-Authenticate” 中添加信息。如下图。
第二步:浏览器在接受到401 Unauthozied后，会弹出登录验证的对话框。用户输入用户名和密码后，浏览器用BASE64编码后，放在Authorization header中发送给服务器。如下图:

第三步: 服务器将Authorization header中的用户名密码取出，进行验证， 如果验证通过，将根据请求，发送资源给客户端，认证结束。
当request第一次到达服务器时，服务器没有认证的信息，服务器会返回一个401 Unauthozied给客户端。认证之后将认证信息放在session，以后在session有效期内就不用再认证了。

三、Http Basic Auth 原理

在HTTP协议进行通信的过程中，HTTP协议定义了基本认证过程以允许HTTP服务器对WEB浏览器进行用户身份认证的方法，当一个客户端向HTTP服务 器进行数据请求时，
如果客户端未被认证，则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证，以决定用户是否合法。
客户端在接收到HTTP服务器的身份认证要求后，会提示用户输入用户名及密码， 用户输入后，
客户端将用户名和密码中间用“：”分隔合并，并将合并后的字符串用BASE64编码，在每次请求数据 时，将密文附加于请求头（Request Header）Authorization: Basic XXXXXXX中。
HTTP服务器在每次收到请求包后，根据协议取得客户端附加的用户信息（BASE64编码的用户名和密码），解开请求包，对用户名及密码进行验证，
如果用 户名及密码正确，则根据客户端请求，返回客户端所需要的数据;否则，返回错误代码或重新要求客户端提供用户名及密码。