避免10 个常见ASP.NET缺陷 使网站平稳运行
Forms Authentication Ticket Lifetime
Forms 身份验证票证生存期
Can you spot the problem with this code:
FormsAuthentication.RedirectFromLoginPage(username, true);
As innocuous as it seems, this code should never be used in an ASP.NET 1.x app unless there is mitigating code elsewhere in the application to counteract this statement’s debilitating effects. If you’re not sure why, then read on.
您能找出以下代码的问题吗？
FormsAuthentication.RedirectFromLoginPage(username, true);
此代码看似没有问题，但决不能在 ASP.NET 1.x 应用程序中使用，除非应用程序中其他位置的代码抵消了此语句的负面作用。如果您不能确定原因，请继续阅读。
FormsAuthentication.RedirectFromLoginPage performs two tasks. First, it redirects a user to the page they originally requested when they were redirected by FormsAuthenticationModule to the login page. Second, it issues an authentication ticket—typically carried in a cookie, and always carried in a cookie in ASP.NET 1.x—that allows the user to remain authenticated for a predetermined period of time.
FormsAuthentication.RedirectFromLoginPage 执行两个任务。首先，当 FormsAuthenticationModule 将用户重定向到登录页时，FormsAuthentication.RedirectFromLoginPage 将用户重定向到他们原来请求的页面。其次，它发布一个身份验证票证（通常携带在 Cookie 中，而且在 ASP.NET 1.x 中总是携带在 Cookie 中），这个票证允许用户在预定的一段时间内保持已经过身份验证状态。
The problem is the period of time. In ASP.NET 1.x, passing RedirectFromLoginPage a second parameter equal to false issues a temporary authentication ticket that expires, by default, after 30 minutes. (You can change the time-out period using a timeout attribute in web.config’s <forms> element.) Passing a second parameter equal to true, however, issues a persistent authentication ticket that’s valid for—get this—50 years! That’s an accident waiting to happen, because if someone steals that authentication ticket, they can access the Web site using the victim’s identity for the life of the ticket. There’s no shortage of ways to swipe authentication tickets—sniffing unencrypted traffic at public wireless access points, cross-site scripting, gaining physical access to a victim’s PC, and so on—so passing true to RedirectFromLoginPage is little better than disabling security on your Web site. Fortunately, this problem was fixed in ASP.NET 2.0. Today’s RedirectFromLoginPage honors the timeout specified in web.config for temporary and persistent authentication tickets alike.
问题就在于这个时间段。在 ASP.NET 1.x 中，向 RedirectFromLoginPage 传递另一个为 false 的参数会发出一个临时身份验证票证，该票证默认情况下在 30 分钟之后到期。（您可以使用 web.config 的 元素中的 Timeout 属性来更改超时期限。）然而，传递另一个为 true 的参数则会发出一个永久身份验证票证，其有效期为 50 年!这样就会发生问题，因为如果有人窃取了该身份验证票证，他们就可以在票证的有效期内使用受害者的身份访问网站。窃取身份验证票证有多种方法 — 在公共无线访问点探测未加密的通信、跨网站编写脚本、以物理方式访问受害者的计算机等等 — 因此，向 RedirectFromLoginPage 传递 true 比禁用您的网站的安全性好不了多少。幸运的是，此问题已经在 ASP.NET 2.0 中得到了解决。现在的 RedirectFromLoginPage 以相同的方式接受在 web.config 中为临时和永久身份验证票证指定的超时。
One solution is to never pass true in RedirectFromLoginPage’s second parameter in ASP.NET 1.x apps. But that’s not very practical because login pages typically feature a "Keep me signed in" box that users can check to receive persistent rather than temporary authentication cookies. An alternate solution is a snippet of code in Global.asax (or, if you prefer, an HTTP module) that modifies cookies containing persistent authentication tickets before they go back to the browser.
一种解决方案是决不在 ASP.NET 1.x 应用程序的 RedirectFromLoginPage 的第二个参数中传递 true。但是这不切实际，因为登录页的特点通常是包含一个“将我保持为登录状态”框，用户可以选中该框以收到永久而不是临时身份验证 Cookie。另一种解决方案是使用 Global.asax（如果您愿意的话，也可以使用 HTTP 模块）中的代码段，此代码段会在包含永久身份验证票证的 Cookie 返回浏览器之前对其进行修改。
Figure 3 contains one such snippet. If present in Global.asax, this code modifies the Expires property of outgoing persistent forms authentication cookies so that the cookies expire after 24 hours. By modifying the line commented "New expiration date," you can set the timeout to whatever you like.
图3 包含一个这样的代码段。如果此代码段位于 Global.asax 中，它会修改传出永久 Forms 身份验证 Cookie 的 Expires 属性，以使 Cookie 在 24 小时后过期。通过修改注释为“新的过期日期”的行，您可以将超时设置为您喜欢的任何日期。
You may find it curious that the Application_EndRequest method calls a local helper method (GetCookieFromResponse) to check outgoing responses for authentication cookies. The helper method is a work-around for another bug in ASP.NET 1.1 that causes a bogus cookie to be added to the response if you check for a nonexistent cookie using HttpCookieCollection’s string indexer. Using the integer indexer as GetCookieFromResponse circumvents the problem.
您可能会觉得奇怪，Application_EndRequest 方法调用本地 Helper 方法 (GetCookieFromResponse) 来检查身份验证 Cookie 的传出响应。Helper 方法是解决 ASP.NET 1.1 中另一个错误的方法，如果您使用 HttpCookieCollection 的字符串索引生成器来检查不存在的 Cookie，此错误会导致虚假 Cookie 添加到响应中。使用整数索引生成器作为 GetCookieFromResponse 可以解决该问题。
from:asp学习网/title:避免10 个常见ASP.NET缺陷 使网站平稳运行/ time:2007-5-20 17:41:09
本文主题,1,ASP,NET
