（有关更多背景信息，请参阅下面的问题）：
是否存在
<machineKey
validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"/>
web.config 中无法在应用程序池回收时自动生成新 machineKey 的情况？ 这是我看到的行为...
我在 MVC 应用程序中使用标准 ASP.NET FormsAuthentication。 如果我使用 FormsAuthentication.GetAuthCookie 登录用户并且不使用持久 cookie（依靠浏览器的会话来记住我的授权状态），我希望回收 IIS 应用程序池以使会话的了解此 cookie...从而注销所有没有持久 cookie 的用户。
这种情况确实发生在我的一个 IIS 安装 (XP) 上，但在不同的 IIS 配置 (服务器 2K3) 上，FormsAuthentication cookie（标准名称“.ASPXAUTH”）仍然有效并继续授权用户。
有谁知道为什么会发生这种情况或者什么配置控制这种行为？
显然，回收应用程序池无法控制浏览器是否仍然发送 .ASPXAUTH cookie（只要我没有关闭浏览器并且 cookie 没有过期）。
如果 IIS 安装在回收后正确拒绝身份验证，我可以在 Application_BeginRequest 事件期间在 Request.Cookies 中看到传入的 cookie...但是一旦控制权移至 Global.asax.cs (Application_AuthenticateRequest) 中可用的下一个事件，Cookie 就会从 Request.Cookies 集合 中删除。
为什么 IIS/ASP.NET 配置不会发生这种情况？
如果不清楚，形成问题的更简单方法是：
为什么 HttpContext.Current.Request.Cookies[".ASPXAUTH"] 从 {System.Web.HttpCookie 更改当我在单个请求中从 Application_BeginRequest 步进到 Application_AuthenticateRequest 时，} 变为 null？
更多调试信息：
如果我将以下代码附加到 Global.asax.cs 的 FormsAuthentication_OnAuthenticate 事件...
var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
var val = cookie.Value;
try
{
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
}
catch (Exception)
{
}
}
...然后在请求之前我回收 IIS 应用程序池时，不会捕获任何异常。 回收 IIS 应用程序池后，当从浏览器发送完全相同的 .ASPXAUTH cookie 时，会捕获加密异常（“填充无效且无法删除。”）
这是为什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web
技术交流群。
（有关更多背景信息，请参阅下面的问题）：
是否存在
<machineKey
validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"/>
web.config 中无法在应用程序池回收时自动生成新 machineKey 的情况？ 这是我看到的行为...
我在 MVC 应用程序中使用标准 ASP.NET FormsAuthentication。 如果我使用 FormsAuthentication.GetAuthCookie 登录用户并且不使用持久 cookie（依靠浏览器的会话来记住我的授权状态），我希望回收 IIS 应用程序池以使会话的了解此 cookie...从而注销所有没有持久 cookie 的用户。
这种情况确实发生在我的一个 IIS 安装 (XP) 上，但在不同的 IIS 配置 (服务器 2K3) 上，FormsAuthentication cookie（标准名称“.ASPXAUTH”）仍然有效并继续授权用户。
有谁知道为什么会发生这种情况或者什么配置控制这种行为？
显然，回收应用程序池无法控制浏览器是否仍然发送 .ASPXAUTH cookie（只要我没有关闭浏览器并且 cookie 没有过期）。
如果 IIS 安装在回收后正确拒绝身份验证，我可以在 Application_BeginRequest 事件期间在 Request.Cookies 中看到传入的 cookie...但是一旦控制权移至 Global.asax.cs (Application_AuthenticateRequest) 中可用的下一个事件，Cookie 就会从 Request.Cookies 集合 中删除。
为什么 IIS/ASP.NET 配置不会发生这种情况？
如果不清楚，形成问题的更简单方法是：
为什么 HttpContext.Current.Request.Cookies[".ASPXAUTH"] 从 {System.Web.HttpCookie 更改当我在单个请求中从 变为 null？Application_BeginRequest 步进到 Application_AuthenticateRequest 时，}
更多调试信息：
如果我将以下代码附加到 Global.asax.cs 的 FormsAuthentication_OnAuthenticate 事件...
var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
var val = cookie.Value;
try
{
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
}
catch (Exception)
{
}
}
...然后在请求之前我回收 IIS 应用程序池时，不会捕获任何异常。 回收 IIS 应用程序池后，当从浏览器发送完全相同的 .ASPXAUTH cookie 时，会捕获加密异常（“填充无效且无法删除。”）
这是为什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们的应用程序是无状态的（不需要会话），但我们遇到了应用程序池回收导致服务器环境上所有机器密钥加密的 cookie 失效的情况（上述问题）。 这是因为机器密钥随着每次回收而变化，而事实不应该是这样。
“本地安全机构 (LSA)”是指分配给应用程序池的用户，请参阅下文了解更多详细信息，因为这就是问题所在。
问题在于我们使用专用用户帐户来运行应用程序池，并且简单地创建用户然后将其分配给应用程序池似乎并没有触发注册表的创建然后存储机器密钥的部分。 您可以通过检查注册表 HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/ProfileList 自行验证这一点
解决方案是在计算机上以该用户身份登录一次（正常的 Windows 登录屏幕），以便创建相关的注册表部分。 不过，可能有更快或更微妙的方法来建立注册表部分。
Our application is stateless (no session required), yet we had a situation where an app pool recycle caused invalidation of all machinekey-encrypted cookies on a server environment (above described issue). This was caused because the machinekey changes with every recycle, which should not be the case.
"Local Security Authority (LSA)" means the user assigned to app pool, see below for more details as this turned out to be the problem.
The issue lied in the fact that we are using a dedicated user account for running the application pool, and simply creating the user and then assigning it to the app pool did not seem to trigger the creation of the registry section where the machine key is then stored. You can verify this yourself by checking registry
The solution was to logon as that user once on the computer (normal Windows logon screen) so that the relevant registry sections are created. There might be quicker or more subtle ways to establish the registry sections though.
Internet 信息服务 (IIS) 7.0（Windows Vista、Windows Server 2008）引入了应用程序池标识，这是一种新的隔离机制，有助于为运行 ASP.NET 应用程序的服务器提供更高的安全性。 但是，以应用程序池标识运行的站点无权访问 HKCU 注册表。 这是 ASP.NET 运行时存储其自动生成的密钥的位置。 结果是，当应用程序池重置时，ASP.NET 无法保留自动生成的密钥。 因此，每次重置 w3wp.exe 时，都会生成一个新的临时密钥。
注意 这在 IIS 7.5（Windows 7、Windows Server 2008 R2）及更高版本中不是问题。 在这些版本的 IIS 上，ASP.NET 可以将其自动生成的密钥保留在不同的位置，从而在应用程序池重置后仍然存在。
https:// support.microsoft.com/en-us/help/2915218/resolving-view-state-message-authentication-code-mac-errors
Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introduced application pool identity, a new isolation mechanism that helps provide increased security for servers that run ASP.NET applications. However, sites that are running under the application pool identity do not have access to the HKCU registry. This is where the ASP.NET runtime stores its auto-generated keys. The result is that ASP.NET cannot persist the auto-generated key when the application pool is reset. Therefore, every time w3wp.exe is reset, a new temporary key is generated.
Note This is not an issue in IIS 7.5 (Windows 7, Windows Server 2008 R2) and later versions. On these versions of IIS, ASP.NET can persist its auto-generated keys in a different location that survives application pool resets.
https://support.microsoft.com/en-us/help/2915218/resolving-view-state-message-authentication-code-mac-errors
表单身份验证 cookie 与会话状态无关。
Forms Authentication cookies have nothing to do with Session state.