Windows Server 2019下Plesk Obsidian中ASP.NET MVC与WordPress登录认证失败问题

你完全不需要认定是站点本身的问题，相同代码在其他环境运行正常、多个完全独立的站点（WordPress和自研ASP.NET MVC）同时出现同类登录故障，已经可以排除站点代码问题，根因100%出在新服务器的全局配置上。

1. 排查全局安全过滤规则 #

• 优先检查Plesk自带的WAF（ModSecurity）规则，大概率是默认开启的恶意请求过滤规则误判了正常表单提交字段，直接丢弃了POST请求中的__RequestVerificationToken、WordPress登录表单参数，导致后端应用收不到对应字段抛出异常。可以临时关闭WAF测试登录功能是否恢复。
• 检查IIS全局安装的第三方安全模块、URL重写模块、缓存模块的全局规则，有没有对POST请求的Body做截断、过滤操作。可以临时禁用所有非系统默认的IIS全局模块，测试登录是否正常，恢复后再逐个开启定位故障模块。
• 排查服务器端安装的杀毒软件、主机入侵防护系统（HIPS）的规则，确认是否存在误拦截正常表单提交的策略。

2. 排查Cookie与会话配置 #

• 检查Plesk全局的Cookie安全配置，确认是否强制设置了不合理的SameSite、Secure、HttpOnly规则，导致前端提交请求时防伪Cookie没有被正确携带，或者前后端Cookie域、路径配置不匹配，后端无法读取对应Cookie。
• 检查IIS全局会话状态配置，确认会话存储方式、超时时间配置是否正确，避免表单提交时会话已经提前失效。
• 确认是否开启了全局页面缓存、CDN缓存，检查登录页、表单提交接口是否被错误缓存，导致返回的防伪Token过期或不属于当前用户。

3. 快速举证方法 #

你可以在ASP.NET站点根目录新增一个临时测试页面，实现最简单的带防伪Token的表单提交逻辑，页面后端打印所有收到的POST参数和Cookie值。如果打印结果中确实缺少__RequestVerificationToken表单字段，即可100%证明是服务器层面对请求做了过滤，可直接将该测试结果提交给服务器服务商，要求他们排查全局配置。

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