Firebase Functions v2中HttpOnly Cookie限制的技术问询

背景 #

使用Firebase Functions v2（const functions = require('firebase-functions/v2')）时，遇到以下平台限制：

• 自动移除__session以外的所有HttpOnly Cookie
• OPTIONS预检请求由Firebase引擎严格管控，无法在functions.https.onRequest中修改；手动设置HttpOnly的__session Cookie后，前端通过fetch+credentials: "include"发起请求时，会触发CORS拦截错误（预检返回的Access-Control-Allow-Credentials为空）

疑问1：Firebase官方认证库如何发送__session Cookie？ #

Firebase Auth的客户端请求并非直接指向你的Firebase Functions域名，而是发往Firebase Auth专属域名（如*.firebaseapp.com或已关联的自定义域名）。这些域名的预检请求由Firebase Auth服务直接处理，会自动返回Access-Control-Allow-Credentials: true，满足浏览器的CORS校验要求。

同时，Firebase Auth设置的__session Cookie是HttpOnly的，不需要通过JS手动拼接Cookie头发送——只要预检请求通过，浏览器会自动在同源请求中携带符合条件的HttpOnly Cookie。

疑问2：实现自定义认证是否需要迁移出Firebase Functions？ #

Firebase Functions的CORS预检限制是平台层面的，Google Cloud Functions（第二代）与Firebase Functions共享底层运行环境，因此会有相同的限制。针对自定义认证（如自定义JWT协议），可考虑以下方案：

• Next.js + Vercel：Next.js的API路由允许完全控制所有请求（包括OPTIONS预检），可自由设置Access-Control-Allow-Credentials及其他CORS头，同时能轻松处理自定义JWT的HttpOnly Cookie设置。
• VPS/独立云服务器：迁移至GCE、AWS EC2等服务器，自行搭建Node.js/Express服务，完全掌控HTTP请求的所有环节，不受Firebase平台的限制。
• 反向代理层：在Firebase Functions前添加Cloudflare Workers等反向代理，通过代理处理OPTIONS预检并设置所需CORS头，再转发请求到Functions。此方式会增加架构复杂度，需权衡成本。

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