Question

身份验证cookie似乎在短时间（一天左右）后超时。我正在使用表单身份验证，并在web.config中使用slidingExpiration =“false”的timeout =“10080”。使用该设置，cookie应在用户成功通过身份验证后约7天到期。

这与IIS6一样广告，但当我将网站移动到IIS7时，cookie过期的速度要快得多。我已经在使用IE和Firefox的多台机器上确认了这种行为，这让我相信它是一个IIS7设置。

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

Answer 1

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

解决问题就像向machine.config添加<machineKey>配置部分一样简单，或者可能（最好是？）添加到服务器上的web.config（未经测试）：

machine.config

Google generate random machinekey表示可以为您生成此部分的网站。如果您的应用程序处理机密信息，您可能希望自己创建密钥。

Answer 2

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

Answer 3

将IIS中配置的会话状态设置为正在处理中使用Cookies 超时=您所需的时间使用托管标识进行模拟

同时将EnableSessionState设置为true（也是默认值）

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

希望你的问题能解决。

Answer 4

首先，我必须说这些“指南”是通用的，而不是iis-7独有的。在<system.web>下的web.config中您要么<sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/>（需要在localhost上运行ASP.NET会话状态服务器服务）或<sessionState mode="InProc" timeout="130" cookieless="false"/>。主要区别在于InProc中会话状态数据放置在应用程序进程本身中。在另一个设置中，不同的服务正在进行存储，您的应用程序只是轮询它以获取所需的数据。使用了两者（以及sql-server会话状态模式），InProc是最不可靠但最快的。 Sql-server是最可靠和最慢的，而StateServer模式在中间的某个地方仅在电源/系统故障的情况下是不可靠的。话虽如此，我必须说，对于请求数较少的网站，性能损失可以忽略不计。

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

您可能遭受应用程序/会话稳定性的原因：

IIS和应用程序池。网站的每个virtul目录都分配给一个应用程序池（默认为“DefaultAppPool”），该应用程序池具有一系列设置，您可以在其中定义该流程“被回收”的时间间隔 - 并因此保留系统资源。如果您不更改设置，应用程序可能会触发流程回收器的一个标准，这意味着您的应用程序已被破坏
病毒。在ASP.NET应用程序中，如果触摸了web.config（以及应用程序所依赖的任何子.config文件）文件，则重新启动应用程序。现在有些情况下，防病毒程序可能会触摸web.config文件（比如每天一次？），因此应用程序重新启动并且会话数据丢失。
配置错误特别是对于表单身份验证，与时间相关的设置和行为始终依赖于Web会话，其中auth会话位于Web会话下。

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

Answer 5

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

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

5 个答案: