Asp.net身份过期会话Cookie

Question

我们正在使用MVC 5.2和ASP.NET Identity框架进行身份验证，使用表单身份验证屏幕（用户和密码组合），并使用cookie保留身份。我在Identity框架的启动方法中配置了将身份验证cookie的到期时间设置为30天，当用户选择“记住我”（IsPersistent = true）时，这种方法很好。当IsPersistent = false（用户选择不选择“记住我”）时，默认情况下会创建会话cookie。此会话cookie在Internet Explorer和FireFox中运行良好，当浏览器关闭时，cookie将丢失。在Chrome和Safari（也可能是其他浏览器）中，有一些选项可以确保会话cookie不会丢失，在这种情况下，即使浏览器关闭并重新打开，用户也会保持登录状态。

我希望能够确保会话cookie不会永久保留，但会在一小时内丢弃。我可以通过检查帐户是否在X分钟/小时内没有活动而且用户从未选择“记住我”来实现这一点，然后如果时间跨度过去，那么用户身份将被“拒绝”下一个请求。

有没有人在他们的ASP.NET身份实现中创建了一个解决方案，以确保会话cookie在X时间之后在后端过期，或者是否有更好的方法来解决此限制？也许可以使用CookieAuthenticationProvider的自定义实现来执行此操作，或者将过期日期/时间交给用户声明，可以在ValidateIdentity过程中的某处进行检查？

任何想法都会很棒。 先感谢您， -Igor

编辑 - 更多信息： 我的身份验证实现有两个基本的“模式”（目前无法想到更好的词）。我的实现是一个简单的用户名/密码表单，带有一个“记住我”的复选框。复选框值传递给AuthenticationProperties对象的IsPersistent属性，该属性传递给AuthenticationManager :: SignIn方法。

1. 用户想要“记住我”，这会创建一个长期存在的cookie，使用滑动过期设置为30天。这使用户能够在浏览器会话之间保持身份验证，并且由于不活动而没有超时，除了不访问该站点超过30天。我的owin启动方法中的设置反映了cookie的到期时间为30天（CookieAuthenticationOptions.ExpireTimeSpan设置为30天）。无论浏览器平台如何，这都有效（据我所知）。

2. 用户不想“记住我”，预期的行为应该是创建会话cookie，当浏览器关闭时，会话cookie将从浏览器中删除。此 应确保在下次启动浏览器时未对用户进行身份验证。当像公共计算机一样使用共享设备时，这一点尤其重要。问题是并非所有浏览器都会删除会话cookie，如果启用了浏览器设置，有些人会故意将它们留下（Chrome就是一个很好的例子）。会话cookie没有到期日期/时间，因此CookieAuthenticationOptions.ExpireTimeSpan在此处没有任何影响。 这是我在寻找建议的地方，因为我相信我不能成为第一个遇到此问题的人。可能有一种方法可以使这种行为更安全，因为替代方法是什么都不做，并且可能在浏览器上留下会话cookie（永不过期！）。

See this link for more detail on Chrome and session cookies.

Answer 1

身份已经在cookie数据中嵌入了到期时间，并由OWIN进行检查。

要将ExpireTimeSpan中的ConfigureAuth方法中的Cookie生命期限{1}}限制为一小时：

Startup.Auth.cs

这将确保Cookie将在一小时后过期。

Answer 2

在Google Chrome中，它与名为Continue where I left off。

的设置有关

在FireFox中，我认为设置为Show my windows and tabs from last time。

如果启用此设置（在您选择的上述浏览器中），则不会删除会话cookie，您的cookie状态无关紧要。使用cookie属性没有直接的解决方法。

解决方法的可能想法

<强>的JavaScript

您可以收听窗口事件window.onbeforeunload，然后在该时间点手动删除Cookie，或者如果用户选择不记住他/她，请求服务器使其无效。此方法假定cookie不是Http或者您可以更改数据库中用户的安全标记，以便下次访问该浏览器上的站点时cookie无效。这可能是最好的使用方法，但也许其他人有更好的想法。

<强>轮询

使用类似SignalR的内容，您可以检查客户端是否仍然可以在身份验证后主动响应（选择一些任意时间间隔）。如果无法访问客户端，则通过更改用户的安全标记使其会话无效。这将要求服务器维护一个活动客户端列表，以便它知道联系谁，如果联系失败则无效。我看到这种方法存在很多问题，我觉得这会产生非常脆弱的代码，如果有短暂的网络干扰，可能会出现一些可能导致服务器无法使用的问题。