Azure部署后MVC应用User.Identity.IsAuthenticated及Session验证失效问题

我之前在部署MVC应用到Azure App Service时，也碰到过完全一样的坑！本地运行好好的，一上Azure就User.Identity.IsAuthenticated和HttpContext.Current.Session["LoggedInUserEmail"]全返回false，咱们一步步拆解问题：

1. 先搞定Membership Providers身份认证失效的问题 #

检查Azure App Service身份验证配置 #

Azure App Service自带的身份验证面板可能覆盖了你代码里的Membership配置！先去Azure门户找到你的App Service，进入身份验证选项卡：

• 如果是用Forms Authentication，要确保没有启用App Service的“内置身份验证”（比如Easy Auth），因为它会拦截你的自定义认证逻辑；
• 要是你确实需要用Membership，得确认web.config里的membership、roleManager节配置正确，特别是连接字符串是不是指向Azure SQL数据库，而且数据库用户有足够的读写权限（本地可能用的是SQL Express，Azure上要确认连接字符串没写错）。

固定MachineKey解决Cookie解密问题 #

Azure App Service的多实例环境下，每个实例默认会自动生成不同的machineKey，这会导致Forms Auth的Cookie在跨实例请求时无法解密，直接判定用户未认证！解决办法是在web.config的<system.web>节里添加一个固定的machineKey：

<system.web>
  <machineKey validationKey="生成的随机密钥" decryptionKey="生成的随机密钥" validation="SHA1" decryption="AES" />
  <!-- 其他配置 -->
</system.web>

你可以用VS工具或者本地生成符合要求的密钥，这样所有实例用同一个密钥，Cookie就能正常解密了。

2. 解决Session丢失的问题 #

本地开发时用的是InProc模式（Session存在内存里），但Azure App Service是多实例负载均衡的，请求可能打到不同的实例，Session自然就没了！

切换到分布式Session存储 #

有几种实用方案：

• Azure Redis Cache：性能最优，配置简单，在web.config里把Session模式改成Redis，填入Redis的连接字符串即可；
• SQL Server Session：把Session存在Azure SQL数据库里，适合不想额外添加Redis服务的场景；
• Azure App Service内置分布式Session：在App Service的配置→常规设置里，把Session模式改成“分布式”，再选择对应的存储源（Redis或SQL）。

临时排查小技巧：启用ARR Affinity #

如果只是临时验证问题，可以先在Azure App Service的配置→常规设置里开启ARR Affinity（应用请求路由亲和性），这样同一个用户的请求会一直打到同一个实例，Session就能暂时正常。但这只是临时方案，生产环境一定要用分布式Session。

3. 代码逻辑小优化 #

你的判断逻辑if (User.Identity.IsAuthenticated || !string.IsNullOrEmpty(Convert.ToString(HttpContext.Current.Session["LoggedInUserEmail"])))其实有个小问题：如果用户已经通过Membership认证，User.Identity.IsAuthenticated应该为true，根本不需要再检查Session。反过来，依赖Session判断登录状态在多实例环境下本来就不可靠，建议优先依赖User.Identity.IsAuthenticated，Session只用来存储非关键的用户辅助信息。

最后，部署后记得清空浏览器缓存，或者用隐私窗口测试，避免旧的无效Cookie干扰！

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