Asp.net 形成身份验证 cookie 不遵守 IIS7 超时

Question

身份验证 cookie 似乎会在短时间内（大约一天）后超时。我正在使用表单身份验证，并且 web.config 中的 timeout="10080" 和 slipExpiration="false" 。通过该设置，cookie 应在用户成功通过身份验证后大约 7 天过期。

这与 IIS6 中宣传的一样有效，但当我将站点移至 IIS7 时，cookie 过期得更快。我已经在使用 IE 和 Firefox 的多台计算机上确认了此行为，使我相信这是 IIS7 设置。

是否存在特定于 IIS7 的与身份验证相关的隐藏设置？除匿名用户跟踪外，网站禁用所有其他身份验证类型。

Answer 1

身份验证 Cookie 使用本地 web.config 或全局 machine.config 中的 machineKey 值进行加密。如果没有显式设置这样的密钥，则会自动生成一个密钥，但它不会持久保存到磁盘上 - 因此，每当应用程序重新启动或由于不活动而“回收”时，它都会发生变化，并且新密钥将在下一次点击时创建。

解决问题就像将 配置部分添加到 web.config 或可能（最好？）到 machine.config（未经测试）：

<system.web>
  ...
  <machineKey 
    validationKey="..."
    decryptionKey="..."
    validation="SHA1"
    decryption="AES"/>
  ...
</system.web>

Google生成随机机器密钥 可以为您生成此部分的网站。不过，如果您的应用程序处理机密信息，您可能需要自己创建密钥。

Answer 2

我的理解是cookie是由消费方——浏览器过期的，这意味着IIS在这方面没有发言权

Answer 3

将 IIS 中配置的会话状态设置为
处理中
使用 Cookie
超时=您需要的时间
使用托管身份进行模拟

还将 EnableSessionState 设置为 true（这也是默认值），

最重要的是在经典模式下运行应用程序池。

希望您的问题能够得到解决。

Answer 4

首先，我必须说这些“指南”是通用的，而不是 iis-7 独有的。
在 下的 web.config 中
您要么有 （这需要 ASP.NET 会话状态服务器在本地主机上运行的服务）
或 。
主要区别在于，在 InProc 中，会话状态数据放置在应用程序进程本身中。在另一种设置中，不同的服务正在执行存储，您的应用程序只需轮询它即可获取所需的数据。
使用这两种模式（以及 sql-server 会话状态模式）后，InProc 是最不可靠但最快的。 Sql-server 是最可靠且最慢的，StateServer 模式处于中间位置，仅在电源/系统故障的情况下不可靠。话虽如此，我必须说，对于请求数较低的网站，性能损失可以忽略不计。

现在，我的经验表明，InProc 的稳定性是相当难以预测的；我曾经和你有同样的问题。我能够通过调整应用程序池的设置来扩展应用程序的稳定性，我通过切换到 SessionState 完全消除了问题（这也允许关闭应用程序而不丢失会话状态数据）。

可能会受到应用程序/会话稳定性影响的原因：

1. IIS 和应用程序池。网站的每个虚拟目录都分配给一个应用程序池（默认为“DefaultAppPool”），该应用程序池具有一系列设置，您可以在其中定义进程“回收”的时间间隔 - 从而保留系统资源。如果您不更改设置，应用程序可能会触发进程回收器的条件之一，这意味着您的应用程序会破坏

2. 杀毒软件破坏。
   在 ASP.NET 应用程序中，如果访问了 web.config（以及应用程序所依赖的任何子 .config 文件）文件，则应用程序将重新启动。现在，在某些情况下，防病毒程序可能会触及 web.config 文件（比如每天一次？），因此应用程序会重新启动并且会话数据会丢失。

3. 配置错误
   特别是对于表单身份验证，与时间相关的设置和行为始终依赖于 Web 会话，并且身份验证会话位于 Web 会话下。

我不知道的是，表单身份验证模块是否仅依赖于会话域，或者它是否也将数据放置在应用程序域中。如果是第二种情况，那么您可能必须禁用应用程序池中的所有回收设置，并再次检查配置/防病毒以及谁存储会话数据。

Answer 5

我最近遇到了同样的问题，即使我将会话超时设置为 2 小时，我的网站也会每 20 分钟超时一次。我发现这是因为 IIS 工作进程每 20 分钟超时一次： http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx