如果选择准确，该属性可以将用户特定的信息添加到视图状态。处理请求时，asp.net 会从视图状态中提取秘钥，并将其与正在运行的页的 viewstateuserkey 进行比较。如果两者匹配，请求将被认为是合法的;否则将引发异常。对于该属性，什么值是有效的？

为所有用户将 viewstateuserkey 设置为常量字符串，相当于将它保留为空。您必须将它设置为对各个用户都不同的值 — 用户 ID，会话 ID 更好些。由于一些技术和社会原因，会话 ID 更为合适，因为会话 ID 不可预测，会超时失效，并且对于每个用户都是不同的。

以下是一些在您的所有页中都必不可少的代码：

void Page_Init (object sender, EventArgs e) {   ViewStateUserKey = Session.SessionID;   :}

为了避免重复编写这些代码，您可以将它们固定在从 page 派生的类的 oninit 虚拟方法中。（请注意，您必须在 page.init 事件中设置此属性。）

protected override OnInit(EventArgs e) {   base.OnInit(e);    ViewStateUserKey = Session.SessionID;}

总体说来，使用基 page 类始终都不失为一件好事，我在 Build Your ASP.NET Pages on a Richer Bedrock 一文中已经进行了说明。如果您要了解更多有关一次单击攻击者的伎俩的信息，可以在 aspnetpro.com 找到一篇非常好的文章。

Cookie 和身份验证

cookie 之所以存在，是因为它们可以帮助开发人员达到一定目的。Cookie 充当了浏览器与服务器之间的一种持续性链接。特别是对于使用单次登录的应用程序来说，失窃的 cookie 正是使得攻击成为可能的罪魁祸首。这对于一次单击攻击来说一点没错。

要使用 Cookie，无需以编程方式显式创建和读取它们。如果您使用会话状态且实现表单身份验证，您会隐式地使用 Cookie。当然，ASP.NET 支持无 cookie 的会话状态，而且，ASP.NET 2.0 还引入了无 cookie 的表单身份验证。因此，理论上您可以在没有 Cookie 的情况下使用这些功能。我并不是说您不再必须这么做了，但事实上这正是疗法比疾病更糟的情形之一。无 Cookie 的会话，实际上将会话 ID 嵌入了 URL 中，这样谁都可以看到。

与使用 Cookie 有关的潜在问题有哪些？Cookie 可能被盗（即被复制到黑客的计算机）和投毒（即被填充以恶意数据）。这些操作通常是即将发起的攻击的前奏。如果被盗，Cookie 会“授权”外部用户以您的名义连接到应用程序（并使用受保护的页），这可能使黑客轻松地规避授权，并能够执行角色和安全设置所允许受害者执行的任何操作。因此，身份验证 Cookie 通常被赋予相对较短的生存期，即 30 分钟。（请注意，即使浏览器的会话完成所需的时间更长，cookie 仍会过期。）发生失窃时，黑客有 30 分钟的时限来尝试攻击。

可以将这个时限加长，以免用户不得不过于频繁地登录;但请注意，这么做会将您自己置于危险境地。任何情况下，都应避免使用 ASP.NET 持续性 Cookie。它将导致 cookie 具有几乎永久的生存期，最长可达 50 年！下面的代码片段演示了如何轻松修改 cookie 的过期日期。

void OnLogin(object sender, EventArgs e) {   // Check credentials   if (ValidateUser(user, pswd)) {      // Set the cookie''s expiration date      HttpCookie cookie;      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);      if (isPersistent)          cookie.Expires = DateTime.Now.AddDays(10);      // Add the cookie to the response      Response.Cookies.Add(cookie);      // Redirect      string targetUrl;      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);   Response.Redirect(targetUrl);   }}

您可以在自己的登录