Azure DevOps API PATCH调用突发401授权失败，求排查方案

问题描述 #

正在将JIRA项目迁移至Azure DevOps，使用Python脚本修复工作项缺失的链接。此前PATCH调用一直正常，近期测试时突然返回401错误。所用PAT令牌在GET、POST请求中可正常工作，且令牌未过期；尝试生成新的全权限PAT，以及仅授予「工作项-读取、写入和管理」权限的PAT（均做base64编码），问题仍存在。

PATCH请求JSON内容：

[
    {
      "op": "test",
      "path": "/rev",
      "value": 81
    },
    {
      "op": "add",
      "path": "/relations/-",
      "value": {
        "rel": "System.LinkTypes.Related",
        "url": "<Link URL>",
        "attributes": {
          "comment": "Making a new link for the dependency"
        }
      }
    }
]

错误信息：

{"$id":"1","innerException":null,"message":"TF400813: The user 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa' is not authorized to access this resource.","typeName":"Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server","typeKey":"UnauthorizedRequestException","errorCode":0,"eventId":3000}

排查步骤 #

• 检查PATCH请求的HTTP头
  确认Content-Type设置为application/json-patch+json，这是Azure DevOps工作项更新API要求的专属Content-Type，普通application/json会导致权限校验异常或请求失败，这是GET/POST和PATCH请求的关键区别之一。

• 验证PAT的权限与范围
  到Azure DevOps组织设置的「个人访问令牌」页面，确认PAT的「组织」范围是否覆盖目标项目，是否设置了IP地址限制；同时检查权限列表中是否包含「工作项」下的所有必要权限（读取、写入、管理）。

• 确认工作项的单独权限设置
  手动在Azure DevOps网页端尝试编辑该工作项的链接，若网页端也无法操作，说明工作项被设置了特殊权限（如仅特定用户组可编辑），需调整工作项级别的权限配置。

• 核对脚本中PATCH请求的认证逻辑
  对比GET/POST请求的认证代码，确认PATCH请求是否正确传递了base64编码的PAT：需遵循用户名:PAT的格式编码（用户名可留空，即:your_pat_string），并在请求头中设置Authorization: Basic <编码后的字符串>。

• 排除服务端临时异常
  查看Azure DevOps服务状态页，确认是否存在权限相关的服务故障；同时用Postman直接发送PATCH请求测试，排除脚本代码的逻辑问题。

• 检查工作项修订号的准确性
  请求中的rev值需与工作项当前的实际修订号一致，若修订号不匹配，部分场景下服务器可能返回不准确的权限错误提示，可先通过GET请求获取工作项最新修订号后重试。

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