Blazor WebAssembly 调用Firestore遇CORS拦截的解决方法

你现在碰到的CORS拦截，根本不是Firebase没配置跨域规则，是自己写的请求代码触发了浏览器的强制预校验，属于典型的自己给自己挖坑：

• 你代码里手动加的Access-Control-Allow-Origin、Access-Control-Allow-Credentials、Access-Control-Allow-Headers三个请求头，全是服务端返回响应时才需要带的响应头，根本不属于客户端能主动加的合法请求头范畴。浏览器检测到这类非法自定义头，会直接把原本不需要预检的简单跨域请求，升级成必须走OPTIONS预校验的复杂请求。
• Firestore的REST服务收到这类带非法自定义头的预校验请求时，不会返回带CORS允许标识的200响应，直接返回非OK状态码，就刚好对应你看到的“预请求没通过HTTP ok状态校验”的报错。

至于为什么Postman能正常跑、Chrome的CORS插件不好使：

• Postman本身根本不执行浏览器的CORS安全校验逻辑，就是个纯发HTTP请求的工具，完全不管跨域规则，测通和浏览器环境能不能跑完全是两码事。
• 大部分CORS插件只会自动补全响应的CORS头，不会帮你清理请求里带的非法自定义头，该触发预检还是触发，自然解不了问题。

这是最符合Firebase官方设计逻辑的方案，不需要额外搭服务就能解决：

1. 先把JS请求代码做最小改动，删掉所有不该存在的CORS相关请求头，修改后的可用代码如下：

   async function sendToken(idToken, userId) {
       try {
           const response = await fetch(`https://firestore.googleapis.com/v1/projects/trailblazor-5ba6f/databases/(default)/documents/users/${userId}`, {
               headers: new Headers({
                   'x-api-key': '你的API Key',
                   'Authorization': 'Bearer ' + idToken,
                   'Content-Type': 'application/json'
               }),
               mode: 'cors'
           });
           const receivedResponse = await response.json();
           if (receivedResponse != null) {
               console.log(receivedResponse);
           }
       } catch (error) {
           return error.message;
       }
   }
   

   删掉这些多余头之后，这个请求就会变成Firestore服务端默认支持的简单跨域请求，不会再触发多余的预检流程。
2. 去Firebase控制台做两个基础校验，避免额外的拦截：
   • 在「认证-设置-授权域」列表里，把本地开发地址https://localhost:44318添加上，这是很多人容易漏的配置，没加的话哪怕请求头完全正确，服务端也会拒绝跨域请求。
   • 检查Firestore的安全规则，确保登录用户有权读取自己对应的用户文档——如果请求返回401/403类的错误码，Firestore会在响应里省略CORS允许头，浏览器也会把这类响应统一判定为CORS拦截，很容易把排查方向带偏。

如果做完上面的修改还是偶现预检失败（比如本地开发时浏览器的预检缓存异常），再考虑搭本地转发代理，这个方案对Blazor WebAssembly场景完全适配：

• 直接在你本地Blazor开发服务的配置里加路由转发，把所有发往/firestore-proxy前缀的请求，转发到https://firestore.googleapis.com的对应路径。这样你在前端代码里把请求地址改成同域的/firestore-proxy/v1/xxx，根本不存在跨域问题，因为所有请求都是发给你自己的本地开发服务的，由服务端代你请求Firestore。
• 注意不要用网上的公共第三方CORS代理，这类代理会截获你传的ID令牌和API Key，有严重的安全风险，本地开发自用的转发代理才是靠谱选项。

• 永远不要在客户端请求里手动携带Access-Control-*系列的头，这类头的唯一作用是服务端告诉浏览器“哪些来源可以访问”，客户端加了纯纯帮倒忙。
• 不要把Chrome的CORS插件当正式解决方案，这类插件本质是修改浏览器的本地安全策略，普通用户的环境根本不会装，生产环境上线后一样会报跨域错。
• 不要迷信Postman的测试结果，两个环境的安全校验逻辑差得非常多。

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