ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Omi 开发版 App 登录成功但每个请求都返回 401 Unauthorized 怎么排查

Omi 开发版 App 登录成功但每个请求都返回 401 Unauthorized 怎么排查 Omi 开发版 App 登录成功但每个请求都返回 401 Unauthorized 怎么排查【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend使用 OmiFriend的 Flutter App 做本地开发时有一类故障现象非常典型App 能正常完成登录看起来一切正常但之后发起的每一个需要认证的 API 请求都被后端拒绝返回401 Unauthorized。登录页不报错只是登录后所有数据都加载不出来。这个问题的根因在仓库文档中有明确结论App 和后端不在同一个 Firebase 项目上。Firebase ID token 是按项目project-scoped签发的为某个 Firebase 项目签发的 token 无法被为另一个项目初始化的后端校验通过所以本地认证看起来成功了而所有认证后的 API 调用都会被拒绝见 docs/doc/developer/AppSetup.mdx 的 Troubleshooting 一节。先确认自己走的是哪条构建路径排查 401 之前先判断你是用自动 setup 还是手动配置的构建因为两条路径下出错的位置不同自动路径bash setup.sh ios或bash setup.sh android针对本地后端 harness 构建devflavor。它使用 Python API端口8000、Firebase Auth 模拟器端口9099和demo-omi-local这个本地 Firebase 项目。手动路径自己配置.dev.env自己选择API_BASE_URL和 Firebase 项目。这条路径下你同时选择了两端也就最容易把两端配到不同的 Firebase 项目上。根因判断App 与后端的 Firebase 项目是否一致文档给出的核心判断规则只有一条App 登录所用的 Firebase 项目必须与后端校验 token 所用的 Firebase 项目是同一个。不一致时登录仍然成功但每个认证请求都会 401。常见触发场景手动构建把API_BASE_URL指到了 Omi 的共享生产 APIhttps://api.omiapi.com/。这个 API 对 Omi 生产 Firebase 项目做 token 校验会拒绝来自demo-omi-local模拟器或你自己 Firebase 项目签发的 token。文档明确说Omi 的共享生产 API 从来不是自配置构建的合法目标。手动构建用了自己的 Firebase 项目登录但后端是为另一个项目初始化的。demo-omi-local的 Firebase 配置是纯模拟器的假凭证setup.sh只会在devflavor 安装这套配置任何 hosted 后端都无法用它通过校验。修复方式本地开发确保 App 指向本地 harness如果你只是想跑本地开发环境正确做法是让 App 和后端都停在本地 harness 这一侧在仓库根目录启动 harnesssetup.sh不会替你启动它make dev-init # 一次性创建 backend/.venv 并复制 env 模板 make dev-up # 启动 Firestore Auth 模拟器和 Python API注意make dev-init用的是当前python3解析到的解释器而后端要求Python 3.11不能是 3.12。没有各模型提供商的 API key 时可以用假 provider 启动PROVIDER_MODEoffline make dev-up到app目录重新执行对应平台的 setupcd app bash setup.sh ios # 或 bash setup.sh android这一步会把devflavor 的 Firebase 配置安装为本地模拟器用的demo-omi-local项目与 harness 是同一套。如果之前手动改过API_BASE_URL文档要求删除 builds 目录并重建 runner后再重新构建否则旧配置可能仍生效。本地 harness 的关键端口与参数可以在 backend/docs/runbooks/local-emulator-manual-qa.md 中查到组件地址Firebase 项目demo-omi-localAuth 模拟器127.0.0.1:9099Python APIhttp://127.0.0.1:8000Redis127.0.0.1:6380iOS 构建以127.0.0.1访问本地服务Android 构建默认使用模拟器宿主别名10.0.2.2。手动构建让 API_BASE_URL 指向与你 Firebase 项目匹配的后端如果走手动路径使用自己的后端修复动作是把.dev.env中的API_BASE_URL指向一个对你自己的 Firebase 项目做 token 校验的后端见 docs/doc/developer/AppSetup.mdx 的 Add API Keys 一节。同时注意API_BASE_URL末尾必须带/否则会得到畸形 URL这是另一类错误但改API_BASE_URL时文档同时提醒了这一点改完API_BASE_URL后要删除 builds 目录并重建 runner 再重新构建。需要访问生产数据使用显式的 beta profiledemo-omi-local的 token 在任何 hosted 后端都过不了校验这是设计如此不是 bug。如果你的开发目标是生产数据文档给出的唯一路径是显式的betaprofile见 app/README.md 的 Mobile beta / dogfood 一节export FIREBASE_SERVICE_ACCOUNT_KEY/secure/path/to/firebase-service-account.json bash setup.sh ios beta# Android beta 使用现有的 prod flavor 和包名 bash setup.sh android beta前提条件文档明确列出Firebase service account 必须能生成生产环境的 mobile 配置beta 的 bundle ID 必须在 Firebase 和 Apple 团队两侧都已注册如果团队使用不同的注册 ID用OMI_MOBILE_BETA_BUNDLE_ID覆盖默认 bundle IDbeta 构建使用mobile_betaprofile 与omi-beta://auth/callbackscheme产品流量走 beta serving APIGoogle/Apple OAuth 仍留在https://api.omi.me/beta 构建不能被当作本地模拟器构建使用——它面向生产数据和demo-omi-local是两套完全不同的凭证体系。FIREBASE_SERVICE_ACCOUNT_KEY指向的 service account 文件路径需要替换为你自己的安全路径。验证修复后按以下顺序确认make dev-status仓库根目录确认 harness 的 API、模拟器都起来了并查看当前端点与 provider 模式。重新在 App 里登录一次再触发任意需要认证的功能拉取数据、发消息等。之前的现象是登录成功 每个请求 401修复后请求应能正常返回数据而不再是401 Unauthorized。桌面本地链路还可以用make dev-verify做登录检查、chat 冒烟与错误检查backend/docs/runbooks/local-emulator-manual-qa.md。如果按上述对齐方式配置后仍然每个请求 401再核对一遍这两点setup.sh是否真的为devflavor 装上了本地模拟器 Firebase 配置这套配置只对 Firebase Auth 模拟器有效不是任何 hosted Firebase 项目的凭证以及API_BASE_URL是否带了结尾的/并且改完后重建了 runner。文档还特别提醒不要对 Omi 的 bundle ID 运行flutterfire configure它会覆盖app/ios/Config/Prod/、app/lib/firebase_options_prod.dart、app/android/app/src/prod/中的预置生产凭证把问题从 401 变成更难定位的凭证错乱。参考App 开发环境搭建与 401 故障说明docs/doc/developer/AppSetup.mdx本地 harness 端口、种子用户与常用命令backend/docs/runbooks/local-emulator-manual-qa.mdMobile beta / dogfood 的构建方式与前提app/README.md【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表