SharePoint SOAP XML查询突发Access Denied错误，求解决方案（错误码0x80070005）

这种突发的权限问题确实头疼，结合你试过调整Authorization头和objXMLHTTP.Open参数都没用的情况，给你几个实际可行的排查方向：

• 先确认身份验证模式是否被改动
  会不会是最近管理员调整了SharePoint站点的身份验证方式？比如从NTLM切换到了OAuth，或者开启了多因素认证（MFA）？如果是这样，传统的用户名密码传参或者简单的Authorization头就完全失效了。你可以先找管理员确认下站点当前的验证机制，要是启用了MFA，得换成支持现代验证的方案，比如通过Azure AD获取访问令牌后再发起SOAP请求。

• 检查账号权限是否被动过
  有时候不是代码的问题，是你的账号权限被悄悄调整了——比如被移除了目标列表/站点的访问权限，或者权限级别被降低了。先手动登录SharePoint站点，直接操作对应的列表（比如查看、添加条目），确认账号权限是否正常。如果手动操作也提示无权限，那直接找管理员恢复权限就行。

• 核对请求头的完整性
  SharePoint的SOAP请求对请求头有不少要求，比如POST请求通常需要X-RequestDigest头，有些环境还对User-Agent的格式有严格限制。你可以对比之前正常运行时的请求头，看看是不是漏了某个关键字段，或者头信息的格式不对。比如有些旧版本的SharePoint会拦截不符合规范的User-Agent，导致权限校验失败。

• 排查网络层面的拦截
  最近有没有换网络环境？比如公司上新了代理服务器，或者防火墙规则更新了？有些代理会拦截带有自定义Authorization头的请求，或者需要额外的代理认证。你可以用Postman这类工具在同一网络下模拟相同的SOAP请求，看看能不能成功——如果工具也报错，那大概率是网络或防火墙的问题。

• 确认SOAP请求的URL是否有效
  虽然之前运行正常，但难保站点没被迁移、路径没被调整。你可以手动访问SOAP服务的URL（比如_vti_bin/lists.asmx），看看能不能正常打开服务页面。如果URL已经失效，那肯定会返回权限错误（其实是找不到资源的伪装报错）。

另外，建议你把当前请求的完整信息（包括请求方法、所有请求头、SOAP体）打印出来，和之前正常运行的请求做对比，差异点往往就是问题所在。

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