4

首先，重要的是要注意，在我的应用程序中，如果您注销您的会话仍然有效，并且您不会只是被重定向回登录页面，而是留在同一页面上。

话虽如此 - 我使用这两种方式中的任何一种在 MVC 应用程序中注销

FormsAuthentication.SignOut()
WebSecurity.Logout()

效果是一样的，如果我立即访问它们，以下属性都不会更改以反映注销：

User.Identity.Name
Thread.CurrentPrincipal.Identity

现在 - 如果我进行重定向，或者只是重新加载页面，那么显然这些属性将更新为空用户。他们只是没有立即表示User.Identity.Name代表刚刚注销的用户。

这是一个问题，因为我想You are logged in as XXX在登录/注销后生成表单的文本 - 这可能是在无法重定向的 AJAX 情况下。

我很好奇是否有任何方法可以IPrincipal在注销（或登录）后触发重置。

我假设人们通常只是Redirect()在Logout()通话之后，所以这从来都不是问题，但在 AJAX 情况下，这并不总是实用的。

我当前的解决方案是在我自己的包装器中抽象身份，因此一旦我退出，我就可以更新它。我只是有点担心这可能会产生一些模糊的副作用，特别是如果有人IPrincipal直接访问而不是通过包装器访问。

4

1 回答 1

4

这是 ASP.NET 事件管道的核心限制，因为它与表单身份验证相关。这也使其容易受到重放攻击，如知识库文章 900111中所述。在那篇文章中，他们引用了一种解决方案来使用存储有关登录用户的一些服务器端信息的成员资格提供程序。

成员资格提供程序似乎与您正在考虑采用的方法非常相似，我想知道您是否应该考虑使用内置的成员资格提供程序之一，或者编写您的自定义代码作为成员资格提供程序。这应该解决人们不理解该方法并直接调用 IPrincipal 的一些担忧。

您的“注销但留在同一页面上”使问题更加突出，但最终您只是发现了每个人在使用 ASP.NET 时遇到的相同的基本重放问题（但不是每个人都能解决它）。

这个相关的问题也可能会有所帮助。

于 2013-02-16T17:55:30.070 回答