FormsAuthentication.SignOut() 不会注销用户

Question

对此我的头撞得太久了。 如何防止用户在使用 FormsAuthentication.SignOut 注销后浏览网站页面？ 我希望这样可以做到：

FormsAuthentication.SignOut();
Session.Abandon();
FormsAuthentication.RedirectToLoginPage();

但事实并非如此。 如果我直接输入 URL，我仍然可以浏览到该页面。 我已经有一段时间没有使用自己的安全性了，所以我忘记了为什么这不起作用。

Answer 1

用户仍然可以浏览您的网站，因为当您调用 FormsAuthentication.SignOut() 时 Cookie 不会被清除，并且它们会在每个新请求时进行身份验证。 MS文档中说cookie将被清除，但他们没有，bug？
和Session.Abandon()一模一样，cookie还在。

您应该将代码更改为：

FormsAuthentication.SignOut();
Session.Abandon();

// clear authentication cookie
HttpCookie cookie1 = new HttpCookie(FormsAuthentication.FormsCookieName, "");
cookie1.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie1);

// clear session cookie (not necessary for your current problem but i would recommend you do it anyway)
SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/sessionState");
HttpCookie cookie2 = new HttpCookie(sessionStateSection.CookieName, "");
cookie2.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie2);

FormsAuthentication.RedirectToLoginPage();

HttpCookie 位于 System.Web 命名空间中。 MSDN 参考。

Answer 2

使用 x64igor 和 Phil Haselden 的上述两个帖子解决了这个问题：

1。 x64igor 给出了执行注销的示例：

• 您首先需要通过在注销响应中传回空 cookie 来清除身份验证 Cookie 和会话 Cookie。

  public ActionResult LogOff() 
    { 
        FormsAuthentication.SignOut(); 
        会话.Clear();   // 这可能不需要——但不会造成伤害 
        会话.放弃(); 
  
        // 清除认证cookie 
        HttpCookie rFormsCookie = new HttpCookie( FormsAuthentication.FormsCookieName, "" ); 
        rFormsCookie.Expires = DateTime.Now.AddYears( -1 ); 
        Response.Cookies.Add( rFormsCookie ); 
  
        // 清除会话cookie  
        HttpCookie rSessionCookie = new HttpCookie( "ASP.NET_SessionId", "" ); 
        rSessionCookie.Expires = DateTime.Now.AddYears( -1 ); 
        Response.Cookies.Add( rSessionCookie ); 
    

2. Phil Haselden 在上面给出了如何在注销后防止缓存的示例：

• 您需要通过响应使客户端上的缓存无效。

   // 使客户端缓存失效 
        Response.Cache.SetCacheability( HttpCacheability.NoCache ); 
        Response.Cache.SetNoStore(); 
  
        // 重定向到主页（应该首先拦截并重定向到登录页面） 
        返回 RedirectToAction( "索引", "主页" );  
    } 
    

Answer 3

在我看来，您没有在 中正确设置 web.config 授权部分。 请参阅下面的示例。

<authentication mode="Forms">
  <forms name="MyCookie" loginUrl="Login.aspx" protection="All" timeout="90" slidingExpiration="true"></forms>
</authentication>
<authorization>
  <deny users="?" />
</authorization>

Answer 4

这里的关键是你说“如果我直接输入 URL...”。

默认情况下，在表单身份验证下，浏览器会为用户缓存页面。 因此，直接从浏览器地址框下拉列表中选择 URL 或输入 URL，可能会从浏览器的缓存中获取页面，并且永远不会返回到服务器来检查身份验证/授权。 解决方案是在每个页面的 Page_Load 事件或基页的 OnLoad() 中防止客户端缓存：

Response.Cache.SetCacheability(HttpCacheability.NoCache);

您可能还想调用：

Response.Cache.SetNoStore();

Answer 5

我以前也曾为此苦苦挣扎。

这是一个似乎正在发生的事情的类比...新访问者 Joe 来到该网站并使用 FormsAuthentication 通过登录页面登录。 ASP.NET 为 Joe 生成一个新身份，并给他一个 cookie。 那块饼干就像房子的钥匙，只要乔带着那把钥匙回来，他就可以打开锁。 每位访客都会获得一把新钥匙和一把新锁以供使用。

当调用 FormsAuthentication.SignOut() 时，系统告诉 Joe 丢失密钥。 通常情况下，这是有效的，因为乔不再拥有钥匙，他无法进入。

但是，如果乔回来，并且确实拥有丢失的钥匙，他就会被允许回来！

据我所知，没有办法告诉 ASP.NET 更换门锁！

我可以接受的方法是在会话变量中记住乔的名字。 当他注销时，我放弃了会话，因此我不再有他的名字。 稍后，为了检查他是否被允许进入，我只需将他的 Identity.Name 与当前会话的 Identity.Name 进行比较，如果它们不匹配，则他不是有效的访问者。

简而言之，对于网站，请勿在不检查会话变量的情况下依赖 User.Identity.IsAuthenticated！

Answer 6

经过大量搜索终于这对我有用。 我希望它有帮助。

public ActionResult LogOff()
{
    AuthenticationManager.SignOut();
    HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);
    return RedirectToAction("Index", "Home");
}

<li class="page-scroll">@Html.ActionLink("Log off", "LogOff", "Account")</li>

Answer 7

这对我有用

public virtual ActionResult LogOff()
    {
        FormsAuthentication.SignOut();
        foreach (var cookie in Request.Cookies.AllKeys)
        {
            Request.Cookies.Remove(cookie);
        }
        foreach (var cookie in Response.Cookies.AllKeys)
        {
            Response.Cookies.Remove(cookie);
        }
        return RedirectToAction(MVC.Home.Index());
    }

Answer 8

该答案在技术上与 Khosro.Pakmanesh 相同。 我发布它是为了澄清他的答案与该线程上的其他答案有何不同，以及可以在哪些用例中使用它。

一般来说，清除用户会话

HttpContext.Session.Abandon();
FormsAuthentication.SignOut();

会有效地注销用户。 但是，如果在同一个请求中您需要检查 Request.isAuthenticated（例如，在授权过滤器中可能经常发生这种情况），那么您会发现

Request.isAuthenticated == true

即使您做了HttpContext.Session.Abandon()和FormsAuthentication.SignOut()。

唯一有效的方法是

AuthenticationManager.SignOut();
HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);

有效设置 Request.isAuthenticated = false。

Answer 9

您发布的代码看起来应该正确删除表单身份验证令牌，因此有问题的文件夹/页面可能实际上并未受到保护。

您是否确认在登录之前无法访问这些页面？

您可以发布您正在使用的 web.config 设置和登录代码吗？

Answer 10

我一直在为我的所有页面编写一个基类，并且遇到了同样的问题。
我有如下代码，但它不起作用。 通过跟踪，控制从 RedirectToLoginPage() 语句传递到下一行，而无需重定向。

if (_requiresAuthentication)
{
    if (!User.Identity.IsAuthenticated)
        FormsAuthentication.RedirectToLoginPage();

    // check authorization for restricted pages only
    if (_isRestrictedPage) AuthorizePageAndButtons();
}

我发现有两种解决方案。
要么修改 FormsAuthentication.RedirectToLoginPage(); 或者通过添加来

if (!User.Identity.IsAuthenticated)
    Response.Redirect(FormsAuthentication.LoginUrl);

修改 web.config

<authorization>
  <deny users="?" />
</authorization>

在第二种情况下，在跟踪时，控制未到达请求的页面。 在遇到断点之前，它已立即重定向到登录 URL。
因此，SignOut() 方法不是问题，重定向方法才是问题所在。

我希望这可以帮助某人

问候

Answer 11

我只是在这里尝试了一些建议，虽然我能够使用浏览器后退按钮，但当我单击菜单选择时，[ActionResult] 的 [Authorize] 令牌将我直接带回到登录屏幕。

这是我的注销代码：

        FormsAuthentication.SignOut();
        Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
        Response.Cache.SetExpires(DateTime.Now.AddSeconds(-1));
        HttpCookie cookie = HttpContext.Request.Cookies[FormsAuthentication.FormsCookieName];
        if (cookie != null)
        {
            cookie.Expires = DateTime.Now.AddDays(-1);
            Response.Cookies.Add(cookie);
        }

虽然浏览器上的后退功能使我返回并显示安全菜单（我仍在研究该菜单），但我无法执行应用程序中安全的任何操作。

希望这可以帮助

Answer 12

我已经尝试了该线程中的大多数答案，但没有运气。 最终结果是：

protected void btnLogout_Click(object sender, EventArgs e)
{
    FormsAuthentication.Initialize();
    var fat = new FormsAuthenticationTicket(1, "", DateTime.Now, DateTime.Now.AddMinutes(-30), false, string.Empty, FormsAuthentication.FormsCookiePath);
    Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(fat)));
    FormsAuthentication.RedirectToLoginPage();
}

在这里找到它： http://forums.asp.net/t/ 1306526.aspx/1

Answer 13

当我设置身份验证>时，这种情况开始发生在我身上。 表格> Web.config 中的路径属性。 删除它解决了问题，并且一个简单的 FormsAuthentication.SignOut(); 再次删除了 cookie。

Answer 14

您可能从一个子域 (sub1.domain.com) 登录，然后尝试从另一子域 (www.domain.com) 注销。

Answer 15

我刚刚遇到了同样的问题，SignOut() 似乎未能正确删除票证。 但仅在特定情况下，某些其他逻辑导致重定向。 当我删除第二个重定向（用错误消息替换它）后，问题就消失了。

问题肯定是页面在错误的时间重定向，因此未触发身份验证。

Answer 16

我现在遇到了类似的问题，我相信我的情况以及原始海报的问题是由于重定向造成的。 默认情况下，Response.Redirect 会导致异常立即冒泡，直到捕获并立即执行重定向，我猜测这会阻止修改后的 cookie 集合传递到客户端。 如果您修改代码以使用：

Response.Redirect("url", false);

这可以防止异常，并且似乎允许 cookie 正确发送回客户端。

Answer 17

只需尝试在按登录时发送会话变量即可。
在欢迎页面上，首先在页面加载或 Init 事件中检查该会话是否为空：

if(Session["UserID"] == null || Session["UserID"] == "")
{
    Response.Redirect("Login.aspx");
}

Answer 18

我想添加一些信息来帮助理解这个问题。 表单身份验证允许将用户数据存储在 cookie 中或 URL 的查询字符串中。 您的站点支持的方法可以在 web.config 文件中配置。

根据 Microsoft< /a>:

SignOut 方法删除表单身份验证票证信息
来自 Cookie 或 URL 如果 CookiesSupported 为 false。

同时， 他们说：

HttpCookieMode 值之一，指示是否
应用程序配置为无 cookie 表单身份验证。
默认为 UseDeviceProfile。

最后，关于 UseDeviceProfile， 他们说：

如果 CookieMode 属性设置为 UseDeviceProfile，则
如果浏览器支持 CookiesSupported 属性，则返回 true
当前请求支持 cookie 和使用 cookie 进行重定向；
否则，CookiesSupported 属性将返回 false。

总而言之，根据用户的浏览器，默认配置可能会导致 CookiesSupported 为 true，这意味着 SignOut 方法不会从 cookie 中清除票证。 这似乎违反直觉，我不知道为什么它会这样工作——我希望 SignOut 在任何情况下都能实际注销用户。

使 SignOut 自行工作的一种方法是在 web.config 文件中将 cookie 模式更改为“UseCookies”（即需要 cookie）：

<authentication mode="Forms">
  <forms loginUrl="~/Account/SignIn" cookieless="UseCookies"/>
</authentication>

根据我的测试，这样做会使 SignOut 自行工作，但会损害您的网站现在需要 cookie 才能正常运行。

Answer 19

对我来说，以下方法有效。 我认为如果“FormsAuthentication.SignOut()”语句后出现任何错误，SingOut 将不起作用。

public ActionResult SignOut()
    {
        if (Request.IsAuthenticated)
        {
            FormsAuthentication.SignOut();

            return Redirect("~/");
        }
        return View();
     }

Answer 20

您是否使用 IE 测试/查看此行为？ IE 可能正在从缓存中提供这些页面。 众所周知，让 IE 刷新其缓存非常困难，因此在很多情况下，即使在您注销后，输入“安全”页面之一的 URL 也会显示之前缓存的内容。

（即使您以其他用户身份登录，并且 IE 在页面顶部显示“欢迎”栏，并显示旧用户的用户名，我也看到过这种行为。现在，通常重新加载会更新它，但如果它是持久的，这仍然可能是一个缓存问题。）

Answer 21

执行 Session.abandon() 并销毁 cookie 效果非常好。 我正在使用 mvc3，如果您转到受保护的页面、注销并查看浏览器历史记录，似乎就会出现问题。 没什么大不了的，但还是有点烦人。

不过，尝试浏览我的网络应用程序上的链接是正确的。

将其设置为不进行浏览器缓存可能是可行的方法。

Answer 22

对于 MVC 这对我有用：

        public ActionResult LogOff()
        {
            FormsAuthentication.SignOut();
            return Redirect(FormsAuthentication.GetRedirectUrl(User.Identity.Name, true));
        }

Answer 23

请注意，如果来自 STS 的 wsignoutcleanup 消息与 IIS 中的应用程序名称与 url 不匹配，WIF 将拒绝告诉浏览器清理 cookie，我的意思是区分大小写< /强>。 WIF 使用绿色“确定”检查进行响应，但不会向浏览器发送删除 cookie 的命令。

因此，您需要注意网址的大小写敏感性。

例如，ThinkTecture Identity Server 将访问 RP 的 url 保存在一个 cookie 中，但它使它们全部小写。 WIF 将收到小写的 wsignoutcleanup 消息，并将其与 IIS 中的应用程序名称进行比较。 如果不匹配，则不会删除 cookie，但会向浏览器报告“正常”。 因此，对于这个 Identity Server，我需要将 web.config 中的所有 url 和 IIS 中的所有应用程序名称都写成小写，以避免此类问题。

如果您有 STS 子域之外的应用程序，也不要忘记在浏览器中允许第三方 cookie，否则即使 WIF 告诉他，浏览器也不会删除 cookie。