PowerShell调用API PUT方法返回403 Forbidden错误求助

一、对比Postman与PowerShell的请求细节 #

• 抓包核对请求头：用Fiddler或Charles分别捕获Postman和PowerShell的请求，重点检查：
  • apitoken格式：脚本中"apitoken" = "$token"是否多套了引号？如果$token本身是无引号的字符串，额外添加双引号可能导致服务器无法识别。
  • Content-Type重复定义：脚本同时在Headers和Parameters的ContentType参数中设置了application/json，部分API服务器会对重复头信息报错，建议只保留一处（推荐保留ContentType参数，Invoke-RestMethod会自动处理头信息）。
  • 隐藏头差异：比如User-Agent，Postman的UA与PowerShell默认UA不同，部分服务器会校验该字段。可以在Headers中添加Postman的UA，例如：

    Headers = @{
        "apitoken" = $token
        "User-Agent" = "PostmanRuntime/7.32.3" # 替换为你Postman实际的UA
    }
    

二、验证Token的获取与传递 #

• 检查Token值准确性：在脚本中添加Write-Host $token打印token，确认其与Postman中使用的token完全一致（无多余空格、换行或特殊字符）。
• 修正Token提取逻辑：Invoke-RestMethod默认会将JSON响应转换为PowerShell对象，若登录接口返回的直接是包含apiKey的对象，无需通过$response.content提取，直接使用：

  $token = $response.apiKey
  

• 避免重复登录：脚本中调用了两次登录接口，部分系统会限制重复登录生成的token有效性，建议只调用一次并保存响应：

  # 移除多余的第一次Invoke-RestMethod调用
  $response = Invoke-RestMethod -Uri "https://mywebsite/api/user/login" -Headers $Header
  $token = $response.apiKey
  

三、核对PUT请求的Body格式 #

• 对比JSON Body内容：将脚本生成的Body与Postman中的Body对比，确保键名大小写、值的格式完全一致。可以通过以下方式输出脚本生成的JSON：

  $Body | ConvertTo-Json | Write-Host
  

  若存在差异，手动调整$Body的键名或值，或使用ConvertTo-Json -Compress压缩格式。
• 检查Body语法正确性：确保JSON无多余逗号、缺失引号等语法错误，部分服务器会因格式问题返回403而非400。

四、调试PowerShell请求构造 #

• 启用Verbose模式：在Invoke-RestMethod中添加-Verbose参数，查看详细的请求发送日志，确认方法、URI、头信息、Body是否符合预期：

  $response = Invoke-RestMethod @Parameters -Verbose
  

• 导出Postman的PowerShell代码：在Postman中导出当前请求为PowerShell代码（Code按钮 -> PowerShell -> Invoke-RestMethod），与你的脚本逐行对比，找出差异点。

五、排查服务器端限制 #

• 检查WAF/防火墙拦截：部分服务器的WAF会拦截PowerShell默认的请求特征，可尝试修改UA或添加常见请求头（如Accept）模拟浏览器/Postman请求。
• 确认权限一致性：确保Postman和脚本使用的是同一账号的token，且该账号确实拥有PUT接口的操作权限。

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