浏览器中HTTP POST请求遇401授权错误，Postman中可正常运行

问题描述 #

发送POST请求时遇到异常：使用包含用户名和密码的Basic认证授权头，在Postman中执行相同请求可正常运行，但使用fetch调用时出现401未授权错误。

Postman的Basic认证头配置：

我的fetch调用代码：

const authHeader = {"Authorization": "Basic **********************"}

fetch(`${url}`, {
          method,
          body,
          headers: authHeader
        }).then((response) => {
          return response.json();
        })

补充信息：该API由PHP编写，部署在AWS ECS环境中。

排查与解决方法 #

• 补全请求头信息
  Postman会自动添加默认请求头（如Content-Type），但fetch不会。根据请求body的格式补充对应头：

  • 若body为JSON格式，需添加："Content-Type": "application/json"
  • 若为表单数据，需添加："Content-Type": "application/x-www-form-urlencoded"
    修改后的headers示例：

  const authHeader = {
    "Authorization": "Basic **********************",
    "Content-Type": "application/json"
  }
  

• 验证Basic认证字符串有效性
  手动生成Base64编码的认证串，和代码中使用的对比：在浏览器控制台执行btoa("用户名:密码")，生成的字符串需与Postman中自动生成的完全一致，避免手动复制时出现空格、字符遗漏等问题。

• 排查CORS配置问题
  浏览器的fetch受CORS规则限制，若前端与API跨域，需确保后端（或AWS ALB）配置正确的CORS响应头：

  • 需返回Access-Control-Allow-Origin指定允许的前端域名
  • 需包含Access-Control-Allow-Headers: Authorization，确保认证头能被正常传递

• 检查PHP后端的认证头读取逻辑
  部分PHP服务器环境下，$_SERVER['HTTP_AUTHORIZATION']变量不会自动设置，导致后端无法获取认证信息。可通过以下方式修复：

  1. 在项目根目录的.htaccess文件中添加规则：

     RewriteEngine On
     RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
     

  2. 或在PHP脚本中手动获取认证头：

     $authHeader = $_SERVER['HTTP_AUTHORIZATION'] ?? $_SERVER['REDIRECT_HTTP_AUTHORIZATION'] ?? '';
     

• AWS ECS相关配置排查

  • 检查Application Load Balancer（ALB）的WAF规则，确认没有拦截包含Authorization头的请求
  • 验证ALB监听器是否配置为传递所有请求头到后端ECS任务
  • 确认ECS任务的安全组允许前端服务器的流量（虽然这通常导致连接错误，但可排除极端情况）

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