Firebase JS SDK 中重定向登录的最佳实践与常见问题解析

背景介绍

在使用 Firebase Authentication 进行 Web 应用身份验证时，重定向登录（Redirect-based login）是一种常见的实现方式。然而，当开发者尝试按照官方文档中的"代理请求"方案（选项#3）进行配置时，可能会遇到"site not found"错误页面。

问题现象

开发者在使用 Firebase JS SDK 的 redirect 登录方式时，配置了应用负载均衡器将 /__/auth 路径的请求代理到 Firebase 应用。但在实际登录流程中，用户会被重定向到一个显示"Firebase 站点未找到"的错误页面。

问题根源分析

经过深入排查，发现这个问题主要由两个配置错误导致：

1. 路径重定向配置错误：初始配置中，负载均衡器将所有 //auth/* 路径的请求重定向到 //auth，导致路径中的 handler 部分被错误地剥离。这使得 Firebase 无法正确处理认证请求。

2. 使用了不恰当的 HTTP 重定向：虽然 HTTP 重定向（301/302）在技术上可行，但在实际应用中会导致登录流程不稳定，出现登录挂起的情况。

正确的解决方案

对于使用 Google Cloud Platform 应用负载均衡器的场景，推荐采用以下配置方案：

1. 创建 Internet NEG 后端：

   • 为 Firebase 实例创建一个互联网网络端点组（Internet NEG）
   • 将所有 /__/ 路径的请求代理到这个后端

2. 负载均衡器配置要点：

   • 使用路径匹配规则精确匹配 /__/auth 路径
   • 确保完整保留原始请求路径和查询参数
   • 避免使用 HTTP 重定向，采用直接代理的方式

技术实现建议

1. 路径保留：确保代理配置不会修改原始请求的任何路径部分，包括 handler 路径段。

2. 查询参数处理：保留所有查询参数，特别是认证流程必需的 apiKey、appName、authType 等参数。

3. 后端服务配置：将 Firebase 应用配置为后端服务，而不是简单的重定向目标。

经验总结

1. 在实现 Firebase 重定向登录时，直接代理优于 HTTP 重定向，能提供更稳定的登录体验。

2. 路径处理是配置中的关键点，任何对原始路径的修改都可能导致认证流程失败。

3. 对于 GCP 环境，Internet NEG 是连接外部服务（如 Firebase）的理想选择。

通过以上配置方案，开发者可以避免常见的"site not found"错误，实现稳定可靠的重定向登录功能。这种方案不仅解决了初始问题，还优化了整体登录流程的可靠性。