Google 登录配置

在 @downcity/services 的 accounts service 里启用 Google OAuth Web Application 登录。

这页讲的是 Google OAuth 的 Web Application 登录接法。

它对应的是 Google Cloud 里的网页应用 OAuth client，不是 Android、iOS、Chrome Extension 或桌面应用 client。

先准备什么

在接入前，你通常需要先有：

一个可用的 Google Cloud Project
能管理这个项目的 Google 账号
准备对外使用的 City 域名
如果你面向公开用户开放登录，最好同时准备好产品主页、隐私政策和支持邮箱

如果这些前置条件没准备好，Client 创建过程和后续 OAuth 审核通常都会卡住。

去哪里找 Google 的 Client ID 和 Client Secret

按 Google 当前官方控制台路径，一般这样操作：

打开 Google Cloud Console
进入 Google Auth Platform
如果这是第一次配置，先完成 Branding 和 Audience
进入 Clients
点击 Create Client
选择 Web application
创建后保存生成的 Client ID 和 Client secret

很多旧教程会写成 APIs & Services -> Credentials。如果你看到的界面和旧教程不一样，以当前 Google Auth Platform 为准。

在 Downcity 里配什么

accounts service 读取下面两个环境变量：

GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET

也就是把 Google OAuth client 里的：

Client ID -> GOOGLE_CLIENT_ID
Client secret -> GOOGLE_CLIENT_SECRET

写进 City env。

回调地址怎么填

accounts service 的 OAuth 回调地址固定是：

https://你的-base-域名/v1/accounts/oauth/callback

例如：

https://downcity.example.com/v1/accounts/oauth/callback

这个地址要登记到 Google OAuth client 的 Authorized redirect URIs。

如果你只是在用 Downcity accounts service 的服务端 OAuth 流程，最关键的是这个回调地址；通常不需要为了这条链路额外去登记产品前端的 JavaScript origin。

Google 控制台里最容易填错的地方

Application type 选错了，没有选 Web application
Authorized redirect URI 填成了产品前端地址，而不是 City 的 /v1/accounts/oauth/callback
真实对外访问域名和 Google 后台登记域名不一致
改了回调地址后立刻测试，Google 配置还没有完全生效

前端怎么接

前端不要把 Google 登录按钮写死，先读服务端真实开放的 provider：

const providers = await guest.service("accounts").get("providers");

如果返回里有：

{ id: "google", type: "oauth", enabled: true }

再展示“Google 登录”入口。

发起登录时：

const start = await guest.service("accounts").action("oauth/start").invoke({
  provider: "google",
  town_id: "town_demo",
});

然后把用户带到返回的 start.url，再通过 oauth/result 轮询或确认结果：

const result = await guest.service("accounts").get("oauth/result", {
  state: start.state,
});

为什么会看到测试模式或未验证提示

如果你的 Google OAuth 配置还没有把 Branding、Audience、域名和相关信息补完整，或者你的 app 仍处在受限测试状态，Google 侧可能会额外拦截或提示。

Downcity 这里只负责标准 OAuth 发起和回调，不会绕过 Google 自己的品牌、受众和校验要求。

这条链路最终会返回什么

Google 登录完成后，accounts service 仍然会按统一方式返回 City user_token。

也就是说，产品侧不需要因为换成 Google 登录，就改掉后面的用户态调用方式：

const user = new City({
  role: "user",
  city_url: "https://base.example.com",
  town_id: "town_demo",
  user_token: result.user_token,
});

常见误区

以为要把前端地址填进 redirect_uri
以为只要有 Client ID 就够了，忘了同时写 Client secret
直接把 Google 登录按钮写死，没有先读 providers
Google Cloud 里建成了别的 client 类型，导致整个回调链路不匹配