Chrome扩展集成Firebase手机号认证时发送OTP出现auth/internal-error错误求助

嗨，我之前在Chrome扩展里折腾Firebase手机号认证时也踩过类似的坑，这个auth/internal-error看起来挺模糊，但基本都是扩展环境的特殊限制或者配置遗漏导致的，咱们一步步来排查：

1. 先检查扩展的Content Security Policy（CSP）配置 #

Chrome扩展的CSP比普通网页严格得多，默认会阻止加载外部脚本和资源，而Firebase的reCAPTCHA、认证请求都需要调用Google的外部服务。你需要在manifest.json里更新CSP规则，允许相关域名的资源：

"content_security_policy": {
  "extension_pages": "script-src 'self' https://www.gstatic.com https://www.googleapis.com; object-src 'self'; frame-src 'self' https://www.google.com;"
}

• https://www.gstatic.com是reCAPTCHA脚本的来源
• https://www.googleapis.com是Firebase Auth API的请求域名
• frame-src允许加载reCAPTCHA的验证框架

如果你的扩展用的是Manifest V2，CSP的写法会略有不同，但核心是要放开这些必要的域名。

2. 确认Firebase和reCAPTCHA的授权域名包含扩展ID #

普通网页的授权域名是你的网站地址，但Chrome扩展的页面域名是chrome-extension://<你的扩展ID>，这个很容易被忽略：

• 打开Firebase控制台 → 认证 → 设置 → 授权域名，添加chrome-extension://<你的扩展ID>
• 打开Google reCAPTCHA控制台（如果你单独配置了reCAPTCHA），同样把这个扩展域名加入允许列表

你可以在Chrome扩展管理页面的“详细信息”里找到你的扩展ID。

3. 调整reCAPTCHA的初始化时机和存储方式 #

你的代码里是点击“发送OTP”时才初始化reCAPTCHA，在扩展的DOM环境下，可能存在容器还未完全挂载或者全局变量window.recaptchaVerifier上下文冲突的问题：

• 改成在组件挂载时初始化，用React的useRef存储实例而不是全局window，避免上下文污染：

import React, { useState, useEffect, useRef } from 'react';
// ...其他导入

const PhoneAuth = () => {
  // ...其他state
  const recaptchaVerifierRef = useRef(null);

  useEffect(() => {
    // 组件挂载时初始化reCAPTCHA
    if (!recaptchaVerifierRef.current) {
      recaptchaVerifierRef.current = new RecaptchaVerifier(auth, 'recaptcha-container', {
        'size': 'invisible',
        'callback': (response) => {},
        'expired-callback': () => {
          console.log('reCAPTCHA expired.');
        }
      });
    }
    // 组件卸载时清理
    return () => {
      if (recaptchaVerifierRef.current) {
        recaptchaVerifierRef.current.clear();
        recaptchaVerifierRef.current = null;
      }
    };
  }, []);

  const sendOtp = async () => {
    try {
      setError('');
      setMessage('');
      const appVerifier = recaptchaVerifierRef.current;
      const formattedPhoneNumber = `+${phoneNumber.replace(/\D/g, '')}`;
      const confirmationResult = await signInWithPhoneNumber(auth, formattedPhoneNumber, appVerifier);
      setVerificationId(confirmationResult.verificationId);
      setMessage('OTP sent successfully');
    } catch (err) {
      // ...错误处理逻辑，注意这里清理的是ref里的实例
      if (recaptchaVerifierRef.current) {
        try {
          await recaptchaVerifierRef.current.clear();
          recaptchaVerifierRef.current = null;
          // 重新初始化
          recaptchaVerifierRef.current = new RecaptchaVerifier(auth, 'recaptcha-container', {
            'size': 'invisible',
            'callback': (response) => {},
            'expired-callback': () => {
              console.log('reCAPTCHA expired.');
            }
          });
        } catch (clearError) {
          console.error('Error clearing reCAPTCHA:', clearError);
        }
      }
    }
  };

  // ...组件渲染部分
};

4. 调试获取更详细的错误信息 #

auth/internal-error是Firebase的通用错误，你可以通过Chrome DevTools抓包看具体的请求响应：

• 打开扩展的DevTools（右键扩展popup → 检查）
• 切换到Network面板，过滤XHR请求
• 点击“发送OTP”后，找到向https://identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode发送的请求
• 查看该请求的Response，里面通常会有更具体的错误描述（比如CSP拦截、域名未授权等）

5. 尝试替换为显式reCAPTCHA #

隐形reCAPTCHA可能在扩展环境下存在兼容性问题，你可以暂时把size改成normal或compact，让reCAPTCHA widget显示出来，用户手动点击验证后再发送OTP，看是否能正常工作。如果显式的能行，再回头排查隐形reCAPTCHA的配置问题。

先从CSP和授权域名这两点入手，这是扩展里最容易踩的坑，很多时候internal-error就是因为请求被CSP拦截或者域名未授权导致的。

备注：内容来源于stack exchange，提问作者Trilochan Behera