1、Cookieless窗体验证
ASP.NET 2.0 支持 cookieless 窗体身份验证。该功能由 forms 元素的 cookieless 属性控制。该属性可以设置为以下四个值之一：
• UseCookies。该值强制 FormsAuthenticationModule 类使用 Cookie 传输身份验证票。
• UseUri。该值指示 FormsAuthenticationModule 类重写 URL 来传输身份验证票。
• UseDeviceProfile。该值指示 FormsAuthenticationModule 类查看浏览器功能。如果浏览器支持 Cookie，则使用 Cookie；否则，重写 URL。
• AutoDetect。该值通过一个动态检测机制指示 FormsAuthenticationModule 类检测浏览器是否支持 Cookie。如果检测逻辑表明不支持 Cookie，则重写 URL。
如果应用程序配置为使用 cookieless 窗体身份验证，并且正在使用 FormsAuthentication.RedirectFromLoginPage 方法，则 FormsAuthenticationModule 类自动设置 URL 中的窗体身份验证票。以下代码示例显示了典型 URL 在重写后的外观：
http://localhost/CookielessFormsAuthTest/(F(-k9DcsrIY4CAW81Rbju8KRnJ5o_gOQe0I1E_jNJLYm74izyOJK8GWdfoebgePJTEws0Pci7fHgTOUFTJe9jvgA2))/Test.aspx
括号中的 URL 部分包含 Cookie 通常将包含的数据。该数据在请求处理过程中由 ASP.NET 删除。该步骤由 ASP.NET ISAPI 筛选器执行，而不是在 HttpModule 类中执行。如果从一个 .aspx 页读取 Request.Path 属性，您在 URL 中不会看到任何额外的信息。如果重定向请求，URL 将自动重写。
注:难以保证 URL 中包含的身份验证票的安全。当安全性极为重要时，您应该使用 Cookie 存储身份验证票。
2、 MemberShip和LoginControl（成员身份和登录控件）
ASP.NET 2.0 引入了MemberShip功能和一组登录 Web 服务器控件，它们简化了使用窗体身份验证的应用程序的实现。
MemberShip为应用程序用户提供凭据存储和管理。它还提供一个MemberShip API，可以在使用窗体身份验证时简化用户凭据的验证任务。该MemberShip功能构建于提供程序模型之上。该模型允许实现和配置指向不同用户存储的不同提供程序。ASP.NET 2.0 包括以下成员关系提供程序：
• Active Directory membership provider。该提供程序使用 Active Directory 或 Active Directory 应用程序模式 (ADAM) 用户存储。
• SQL Server membership provider。该提供程序使用 SQL Server 用户存储。
还可以添加对自定义用户存储的支持。例如，可以添加对其他轻量级目录访问协议 (LDAP) 目录或其他现有公共标识存储的支持。为此，创建一个从 MembershipProvider 抽象基类继承的自定义提供程序。
ASP.NET 登录控件自动使用MemberShip和窗体身份验证，并封装提示用户输入凭据，验证用户，恢复或替换密码等所需的逻辑。实际上，ASP.NET 登录控件在窗体身份验证和MemberShip上提供一个抽象层，并且取代了您使用窗体身份验证时通常必须进行的大多数或全部工作。
3、 Web Farm Scenarios(Web 场方案)
在 Web 场中，无法确保哪个服务器将处理连续请求。如果用户在一台服务器上经过身份验证，但下一个请求在另一台服务器上进行，则身份验证票将导致验证失败并请求用户重新进行身份验证。
machineKey 元素中的 validationKey 和 decryptionKey 属性用于对窗体身份验证票进行哈希操作和加密。这些属性的默认值为 AutoGenerate.IsolateApps。这些密钥是针对每个应用程序自动生成的，在每台服务器上都不同。因此，在一台计算机上加密的身份验证票无法在 Web 场中的另一台计算机或者同一台 Web 服务器上的另一个应用程序中进行解密和验证。
为了解决该问题， Web 场中所有计算机上的 validationKey 和 decryptionKey 值都必须相同。