跳至内容
WebViewGold 从 Vibe Coding 到 App Store
中文
获取 WebViewGold

ChatGPT & Codex

WebView 应用中的 Google 登录和 Sign in with Apple:Firebase Auth 的 Codex 工作流程

在封装的 Web 应用中,有两件事会让登录失败:Google 拒绝在嵌入式 WebView 中进行 OAuth,而 Apple 会拒绝那些提供了 Google 登录却没有同等隐私友好选项的应用。WebViewGold 以原生方式解决了第一个问题,并在 iOS 上自动识别 Sign in with Apple;Codex 负责让 Web 端与之配合。本指南以托管在 Express 上的 Firebase Auth 应用为例,在这种技术栈中重定向的细节最为关键。

每个平台一次性 $109 起,或由我们的团队全程代劳,$698 起。

  • 审核通过保证 – 否则 14 天内退款
  • 无需编程
  • 一次性付费,免费更新
  • 7×24 小时人工支持
  • 2014 年起德国出品 · ISO 27001

目标,以及审核人员的十秒测试

目标是提供三种登录方式,它们在 iOS 和 Android 应用内的表现与网页上完全一致:电子邮件、Google 和 Sign in with Apple,最终都进入 WebView 中同一个 Firebase 会话,并且在关闭再重新打开应用后依然保持登录。

审核人员的测试很简短。他们点按 Google;如果 Google 返回“Error 403: disallowed_useragent”,应用就算是坏的(准则 2.1)。接着他们会在 Google 旁边寻找 Apple 选项;如果没有,准则 4.8 要求提供一种只收集姓名和电子邮件、并允许用户隐藏邮箱地址的登录方式,实际上就是 Sign in with Apple。只使用自有邮箱账号或魔法链接账号的应用不受此限制,这也是一条正当的出路(准则 4.8 详解)。

关于 Google 错误的背景知识见 disallowed_useragent 修复指南,所有登录方式都汇总在 Google 登录和 Sign in with Apple 专题中。

三个层面,三个负责方

WebViewGold:Social Login Helper

Google 会阻止嵌入式 WebView 中的 OAuth。当加载的 URL 匹配 google_login_helper_triggers(Config.swift)中的条目时,WebViewGold 会在一个专用窗口中以 Google 接受的 User-Agent 打开登录页面,完成后返回您的应用;Android 在 Config.java 中有同样的列表 GOOGLE_LOGIN_HELPER_TRIGGERS,外加 Facebook 的列表。Sign in with Apple(appleid.apple.com)在 iOS 上会被自动处理。参见社交登录文档。

您的 Web 应用:在自己的域名上完成重定向

Safari 和其他 WebKit 视图会阻止第三方存储,只要 authDomain 仍指向 PROJECT.firebaseapp.com,Firebase 的重定向登录就会失效。Firebase 的重定向最佳实践列出了几种修复方法;对于运行在 Express 上的应用,最干净的做法是在您的域名上为 /__/auth/ 设置反向代理,并把 authDomain 设为该域名。

Apple Developer:Services ID 和密钥

一个包含您的域名和返回 URL https://app.example.com/__/auth/handler 的 Services ID(因为使用了代理,所以是您自己的域名)、一个 Sign in with Apple 密钥和您的 Team ID,全部填入 Firebase 的 Apple 提供方设置中。

Android:Apple 登录是可选的

Google Play 没有关于 Sign in with Apple 的规定。只有在您的用户期望时才在 Android 上显示这个按钮,并在真机上测试该重定向;WebViewGold 的 Apple 自动处理在文档中是针对 iOS 说明的。

AGENTS.md 中的身份验证段落

把这段加在您 AGENTS.md 中运行环境说明的下方。它可以阻止代理在 WebView 中登录失败时常做的三件事:修改 User-Agent、在新窗口中打开 OAuth,或者悄悄地把 Google 从 iOS 构建中移除。

markdown
## Authentication (Firebase Auth inside WebViewGold)
- Providers: email/password, Google, Apple. Google and Apple buttons live in one
  component (src/components/SocialButtons.tsx) with equal size and prominence.
- Every sign-in call goes through src/lib/auth.ts. Inside the native app
  (isNativeApp()) use signInWithRedirect, which Firebase recommends on mobile;
  keep the method in one constant so we can switch to popup after device tests.
  Desktop browsers may use signInWithPopup.
- authDomain is our own domain (app.example.com). Express proxies /__/auth/* to
  PROJECT_ID.firebaseapp.com as a transparent reverse proxy. Never point
  authDomain back to firebaseapp.com.
- Google inside the app works through WebViewGold's Social Login Helper
  (google_login_helper_triggers / GOOGLE_LOGIN_HELPER_TRIGGERS). Do not change the
  user agent, do not open OAuth URLs with window.open, do not use googlelogin://
  unless explicitly asked.
- Sign in with Apple (appleid.apple.com) is handled by WebViewGold on iOS.
- Apple shares the name only on the first sign-in: write displayName to users/{uid}
  immediately. Expect @privaterelay.appleid.com addresses.
- auth/account-exists-with-different-credential: ask the user to sign in with the
  existing method, then linkWithCredential. Never create a second account silently.

我的iOS WebView应用终于通过审核了。谢谢!!

塔哈·法鲁基(Taha Farooqui) · CodeCanyon

Codex 提示词

在 Web 应用仓库中用 codex --sandbox workspace-write --ask-for-approval on-request 运行。它只修改代码;所有需要您在 Apple 和 Firebase 控制台中点击完成的事项,都会整理到一个设置文件里交给您。

粘贴到 Codex(CLI 或 IDE 扩展)
请阅读 AGENTS.md,尤其是 Authentication 部分。我们的应用使用 Firebase Auth,支持电子邮件/密码和 Google 登录。Apple 依据准则 4.8 拒绝了 iOS 构建版本,而且在部分设备上,应用内的 Google 登录会因 disallowed_useragent 失败。请修复 Web 端;Apple Developer 和 Firebase 控制台以及 WebViewGold 配置由我来处理。

1. 使用 new OAuthProvider("apple.com") 和 email、name 两个 scope 添加 Sign in with Apple,统一经由 src/lib/auth.ts 处理。按钮遵循 Apple 的设计规范(黑色或白色、Apple 标志、“Sign in with Apple”文字),并与 Google 按钮的尺寸和醒目程度相同。
2. 在原生应用内(isNativeApp()),使用 signInWithRedirect,并在应用启动时处理 getRedirectResult,包括错误情况:显示可见的提示信息,而不是静默失败。桌面浏览器保留弹窗流程。把方式的选择放在一个常量中。
3. 让 authDomain 使用我们自己的域名:添加一个 Express 反向代理,把 /__/auth/ 转发到 https://PROJECT_ID.firebaseapp.com(透明代理,而不是重定向;保留路径、查询字符串和 Cookie)。从环境变量中读取 PROJECT_ID 和身份验证域名。
4. 用户首次使用 Apple 登录时,如果 users/{uid} 中的 displayName 和 email 为空,就写入它们。
5. 用账号关联流程处理 auth/account-exists-with-different-credential:说明该账号使用的是哪种登录方式,用该方式登录,然后调用 linkWithCredential。
6. 编写 SETUP-AUTH.md,列出我必须配置的内容:域名为 app.example.com、返回 URL 为 https://app.example.com/__/auth/handler 的 Apple Services ID,Firebase 所需的密钥和 Team ID,Firebase 中的授权域名,以及需要检查的 WebViewGold 设置(Config.swift 中的 google_login_helper_triggers、Config.java 中的 GOOGLE_LOGIN_HELPER_TRIGGERS、deletecache 关闭)。
7. 测试:为账号关联流程、重定向错误处理以及代理路由(使用模拟的上游服务)编写单元测试。不要调用 Google 或 Apple。
最后报告修改过的文件,以及一份 iOS 和 Android 的真机测试矩阵。

WebViewGold 这一侧

这些是文档中的默认值。只有当您的登录流程会经过其他 Google 或 Facebook 主机时才需要扩展这些列表(在桌面浏览器中发起登录并观察重定向)。在 Android 上,同样的前缀要填入 Config.java 中的 GOOGLE_LOGIN_HELPER_TRIGGERS 和 FACEBOOK_LOGIN_HELPER_TRIGGERS。

swift
// Config.swift: Social Login Helper triggers (documented defaults)
var google_login_helper_triggers: [String] = ["https://accounts.google.com", "https://accounts.youtube.com"]
var facebook_login_helper_triggers: [String] = ["https://m.facebook.com", "https://www.facebook.com"]

// Sign in with Apple (appleid.apple.com) needs no trigger: WebViewGold handles it on iOS.

// Keep sessions across launches: leave deletecache and deletecacheonexit off,
// or users are logged out every time they open the app.
// Custom user agent (useragent_iphone / useragent_ipad): append your marker to the
// default string instead of replacing it.

工作顺序

  1. Apple Developer 账号

    在 App ID 上启用 Sign in with Apple,创建一个 Services ID,注册 app.example.com 和返回 URL https://app.example.com/__/auth/handler,创建一个 Sign in with Apple 密钥,并记下 Key ID 和 Team ID。

  2. Firebase 控制台

    启用 Apple 提供方(Services ID、Team ID、Key ID、私钥)和 Google。把 app.example.com 添加到授权域名中。

  3. 运行 Codex 任务并审阅

    粘贴提示词,然后在 CLI 中运行 /review 并阅读 git diff。先检查代理:它必须是转发而不是重定向,并且不能影响其他路由。

  4. 部署并检查 handler

    在浏览器中打开 https://app.example.com/__/auth/handler。它应该由您的域名提供,而不是返回 404 或跳转到 firebaseapp.com。

  5. 原生配置

    确认触发列表,iOS 上保持 deletecache 关闭,Android 上保持 CLEAR_CACHE_ON_STARTUP 关闭;如果您设置了自定义 User-Agent,请在默认字符串后追加,而不是替换。在 Android 上,可以让 HOME_URL_LOGOUT 指向您的登出 URL,以清除登录 Cookie。

  6. 跑完真机矩阵,然后提交

    在 TestFlight 和内部测试轨道上跑完下面的测试矩阵。在审核备注中列出登录方式,并给审核人员一个电子邮件演示账号(提交的其余步骤见 Codex 发布工作流程)。

真机测试矩阵

  • iOS,新的 Apple 用户:姓名被保存,私密中转邮箱地址被接受,用户登录成功。
  • iOS,回访的 Apple 用户:进入同一个账号,没有重复账号。
  • iOS 和 Android,Google:没有 disallowed_useragent,流程结束后以登录状态返回应用。
  • 电子邮件和密码登录依然可用,审核人员的演示账号第一次就能登录。
  • 使用其他提供方注册的现有账号会触发账号关联流程,而不是创建第二个账号。
  • 关闭再重新打开应用:依然保持登录。
  • 退出登录,然后再次用 Google 登录:出现账号选择器,而不是静默登录到之前的账号。

常见陷阱

  • authDomain 仍留在 firebaseapp.com。重定向能完成,但应用常常回到登录页面,且没有用户。
  • Services ID 中的返回 URL 不完全匹配:用了 http 而不是 https、末尾多了斜杠,或者已迁移到自己的域名后仍使用 firebaseapp.com 主机。
  • Apple 按钮比 Google 按钮小,或者藏在它下方。Apple 的设计规范要求同等醒目,审核人员会对比。
  • 私密中转邮箱地址永远收不到您的邮件。请在 Apple Developer 账号的“Sign in with Apple for Email Communication”中注册您的发信域名。
  • Codex 提议把应用的 User-Agent 替换成桌面版 Chrome 的字符串。这会破坏移动端布局,而且没有必要;Social Login Helper 才是受支持的方式。
  • 把 googlelogin:// 当作默认方案。它在 iOS 上把登录交给系统浏览器,在 Android 上交给 Chrome Custom Tab,所以除非您的重定向把会话带回来,否则会话存在于 WebView 之外。请只在特殊情况下使用它(Android URL 处理文档)。

常见问题

WebViewGold 需要为 Sign in with Apple 做配置吗?

在 iOS 上不需要:appleid.apple.com 的流程会被自动识别和处理。您需要在 Apple Developer 账号和 Firebase 中配置 Apple,并在 Web 应用中添加按钮。

Android 上需要 Sign in with Apple 吗?

不需要。Google Play 没有这样的规定。很多应用为了保持一致会在两个平台上都显示它;如果您也这样做,请在发布前在 Android 设备上测试该流程。

应用内应该用弹窗还是重定向?

先在您自己的 authDomain 上使用重定向,这也是 Firebase 针对移动端的推荐做法。把选择放在一个常量中,这样如果真机测试发现问题,就能切换到弹窗;每次改动后都要在两个平台上重新测试。

Codex 能自己测试 OAuth 流程吗?

不能。OAuth 需要真实的提供方账号,而 Codex 沙盒默认没有网络访问权限。Codex 可以用模拟数据测试账号关联逻辑、错误信息和代理路由;真实的登录测试属于您的真机矩阵。

如果我用 Supabase 而不是 Firebase,会有什么变化?

WebViewGold 这一侧完全相同。在 Supabase 中,您用 Services ID 和由密钥生成的 client secret 启用 Apple 提供方(Apple 将其有效期限制为六个月,所以要规划好轮换),回调 URL 是您 Supabase 项目的 auth 回调地址。不需要搭建 authDomain 代理。

让您的应用上架商店的三种方式

结果相同,只是您需要投入的工作量不同。三种方式都附带审核通过保证和 7×24 小时人工支持。

自己动手

$109 每个平台,一次性付费

WebViewGold 许可证:一个现成的 Xcode 或 Android Studio 项目。粘贴您的 URL,设置名称和图标,开启所需功能,构建并提交。永久免费更新。

在主页查看方案

Cloud Builder

$349 每个许可证,一次性附加购买

无需 Mac、Xcode 或 Android Studio:在浏览器中完成配置,我们在云端构建两个应用,并将其交付到 App Store Connect 和 Play Console。

Cloud Builder 如何运作 试用免费演示

Full Service

$698 每个平台 $798

把您的 URL 和图标发给我们。我们的团队在 72 小时内完成配置、构建并交付您的应用,白标,附源码项目。两个平台共 $1,158。

Full Service 详情 服务提供方: WeSetupYourWebViewApp

冬季特惠价格有效期至 2026年12月31日。

准备好发布您的应用了吗?

App Store & Google Play 审核通过保证 – 否则 14 天内退款

想直接交给我们?Full Service:我们在 72 小时内完成配置、构建并交付,每个平台 $698 起。有疑问?通过 7×24 小时在线聊天联系我们。

退款依据我们 FAQ 中列出的条件:应用因非内容原因被 Apple 和/或 Google 拒审,并在购买后 14 天内提出申请。