从首个Azure静态Web应用调用第二个时获取响应的CORS问题排查

核心问题分析 #

• 你在请求头中添加了Access-Control-*系列头，这是错误的：这些头是由被请求的服务（第二个静态Web应用）在响应中返回的，而非请求方携带。
• 静态Web应用的staticwebapp.config.json配置需要针对跨域场景做精准设置，仅添加globalHeaders不足以处理预检请求和凭证传递。

分步解决方案 #

1. 修正前端请求代码 #

移除请求头中的所有Access-Control-*字段，保留用户凭证相关的自定义头即可：

getUserInfo()
.then(async (clientPrincipal) =>  {
  console.log(clientPrincipal);
  const response = await fetch(url_of_2nd_azure_static_web_app, {
    headers: {
      'X-MS-CLIENT-PRINCIPAL-NAME': clientPrincipal.userDetails,
      'X-MS-CLIENT-PRINCIPAL-ID': clientPrincipal.userId
    },
    // 若需传递Cookie等凭证，需添加该配置
    credentials: 'include'
  });
});

2. 配置第二个Azure静态Web应用的CORS规则 #

在第二个应用的staticwebapp.config.json中，添加专门的CORS配置，而非仅依赖全局头：

{
  "routes": [],
  "globalHeaders": {},
  "cors": {
    "allowedOrigins": ["https://第一个静态Web应用的域名"],
    "allowedMethods": ["GET", "OPTIONS"],
    "allowedHeaders": ["X-MS-CLIENT-PRINCIPAL-NAME", "X-MS-CLIENT-PRINCIPAL-ID"],
    "allowCredentials": true
  }
}

注意：allowedOrigins建议指定具体域名而非*，当需要传递凭证时，*会和allowCredentials: true冲突，导致跨域验证失败。

3. 处理预检请求（OPTIONS） #

Azure静态Web应用会自动处理OPTIONS预检请求，只需确保配置中allowedMethods包含OPTIONS，且allowedHeaders覆盖你自定义的凭证头即可。

4. 更安全的凭证传递方式（可选） #

直接传递自定义头存在安全风险，建议使用Azure静态Web应用的内置身份验证令牌：

• 从第一个应用获取用户的ID令牌（clientPrincipal.identityToken）
• 请求第二个应用时，将令牌放在Authorization头中：

const response = await fetch(url_of_2nd_azure_static_web_app, {
  headers: {
    'Authorization': `Bearer ${clientPrincipal.identityToken}`
  },
  credentials: 'include'
});

• 第二个应用可通过内置身份验证中间件自动验证令牌，无需手动处理凭证校验逻辑。

验证步骤 #

1. 重新部署两个应用的配置和代码
2. 用浏览器开发者工具的网络面板，检查OPTIONS请求的响应头是否包含正确的Access-Control-*字段
3. 确认GET请求的响应状态码为200

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