切换IIS物理路径后ASP.NET MVC应用会话未按预期过期的咨询

我之前部署ASP.NET MVC应用时也碰到过一模一样的情况，咱们来捋捋为啥会这样，以及怎么解决：

为啥修改物理路径后用户没被强制登出？ #

主要有这几个常见原因：

• 会话状态存在外部存储：如果你的应用用的是StateServer或者SQLServer模式保存会话（而非默认的InProc），修改物理路径并不会清空这些外部存储里的会话，用户的会话自然还能继续使用。
• 表单认证Cookie仍有效：ASP.NET的Forms认证Ticket存在客户端Cookie中，如果开发/预发布环境和生产环境用了相同的machineKey，客户端的旧Cookie依然能被新路径下的应用验证通过，用户就不用重新登录。
• IIS应用池回收延迟：理论上修改站点物理路径会触发应用池回收，但有时候IIS的回收机制有延迟，旧的应用进程还在运行，会话还没被销毁。

解决办法 #

针对上面的原因，你可以试试这些方案：

1. 手动回收应用池 #

修改物理路径后，直接在IIS管理器里找到对应生产站点的应用池，右键选择「回收」，强制杀死旧进程，这样InProc模式下的会话会被彻底清空。

2. 调整表单认证配置，让旧Cookie失效 #

• 更新machineKey：在Web.config里修改machineKey的validationKey和decryptionKey（可以用工具生成新密钥），这样旧的认证Ticket就无法被新应用验证，用户会被强制跳转到登录页。
• 修改Cookie路径或名称：在Forms认证配置里，给name属性加个版本后缀（比如从.ASPXAUTH改成.ASPXAUTH_v2），或者调整path属性，这样客户端的旧Cookie就不会被新应用识别。
• 主动让Cookie过期：在应用启动时（比如Global.asax的Application_Start方法里），添加代码强制让旧认证Cookie过期：

if (Request.Cookies[FormsAuthentication.FormsCookieName] != null)
{
    var cookie = new HttpCookie(FormsAuthentication.FormsCookieName)
    {
        Expires = DateTime.Now.AddDays(-1),
        Path = FormsAuthentication.FormsCookiePath
    };
    Response.Cookies.Add(cookie);
}

3. 清理外部会话存储（如果使用了的话） #

如果是用StateServer，可以重启ASP.NET State Service服务；如果是SQLServer模式，执行SQL脚本清空会话数据库里的记录（比如DELETE FROM ASPStateTempSessions）。

4. 部署时加入强制登出逻辑 #

可以在发布脚本里添加步骤：回收应用池、重启相关服务，或者在应用启动逻辑里检查当前部署版本，和客户端Cookie里的版本对比，不一致就强制用户登出。

内容的提问来源于stack exchange，提问作者code_bender