拓冰网站定制 
AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载导读本文基于 Operit 仓库中 github_oauth_completion_delivery 系列设计文档系统讲解「GitHub OAuth 完成回调Completion URL由应用自身持有与协调」的落地改造为何要把浏览器回调注册与导航处理从operit-host-apiHost API中移除、Core 在待领取凭据与一次性领取中承担何种职责、Flutter 市场对话框与 Rust CLI 如何各自完成浏览器展示与完成 URL 捕获以及该改造在 Operit Android 端的源码级实现。读完本文你将掌握 OAuth 完成回调的职责边界划分、一次领取one-time claim协议的调用链以及 Flutter/CLI/Android 三类登录面的应用自有协调模式。背景被伪装成 Host 能力的应用交互未发布实现的问题在本次改造之前仓库中存在一套**未发布unshipped**的实现它把通用的浏览器回调注册generic browser callback registration与导航处理navigation handling放进了operit-host-api中同时 Flutter 侧的运行时浏览器注册表runtime browser registry也承担了同样的回调逻辑。从职责划分看这带来了一个架构性偏差浏览器回调托管本应是应用App交互的一部分却被打扮成了 Core Host 的通用能力。具体表现为浏览器完成地址的注册、导航的捕获与中转被耦合进 Host API 层任何需要 OAuth 登录的应用都必须依赖 Host 提供的回调托管Flutter 的浏览器注册表回调通道成为多余的第二套回调链路Core 的职责边界被稀释——它既要维护待领取凭据又间接参与了浏览器呈现。改造方向把浏览器呈现还给应用2_AppOwnedCoordination.md 明确列出了四项核心改动移除operit-host-api中的BrowserCallbackHost及其传输类型transport types保留Core 的 broker 服务职责维护待领取凭据pending credentials、校验、一次性领取one-time claim以及已持久化的 GitHub 认证Flutter 市场对话框自己呈现授权页并把捕获到的完成 URL 交给 CoreCLI自己预留 loopback 监听器、打印授权 URL、等待回调再把完成 URL 交给 Core。此外还要移除 Flutter 未使用的浏览器注册表回调通道unused Flutter browser-registry callback channel。从源码结构看这一改造把「浏览器呈现 完成检测」两个职责彻底划给了应用层而 Core 退回到纯粹的交易与凭据管理角色——这与配套文档 1_Protocol.md 中「每个应用拥有自己的浏览器呈现与完成检测」的协议定位完全一致。完成协议Worker 创建、应用交付、Core 一次领取交易的创建与完成重定向协议侧的完整设计见 1_Protocol.mdWorker 创建一个awaiting_callback交易transaction交易内包含PKCE verifier、经过哈希的一次性领取凭据hashed one-time delivery credential以及一个经过校验的完成重定向 URLvalidated completion redirect URLGitHub 回调 Worker 后Worker 完成授权码交换code exchange与载荷加密payload encryption然后仅以transactionId与statuscomplete两个参数重定向浏览器取消与交换错误同样以完成状态completion statuses表示并且交易会被删除完成 URL 从不携带 GitHub token 或领取凭据应用在 Worker 交易开始前就准备好允许的回调目标allowed callback destination呈现授权 URL只接受导航到该目标的结果并把完成的 URL 返回给 Core。Core 的私有存储与一次性领取应用在 Core 启动交易之前准备目标地址Core 把不透明的交易 ID 与领取凭据保存在**客户端私有存储client-private storage**中随后对比返回的完成目标destination与交易 ID匹配后才调用POST /oauth/github/claimWorker 在成功领取时删除交易因此不存在任何完成轮询端点no completion polling endpoint exists。这套设计同时解决了两个实际问题见 index.md旧的 broker 客户端在用户授权期间反复调用 Worker把空闲授权时间放大成了请求与 D1 读取量改为「Worker 存储加密结果后只投递一次不透明完成 URL」后客户端 Core 保持领取凭据私密、校验返回的交易 ID 与回调目标、并只领取一次。Android 端源码印证Core 协调器的两次调用启动交易startLogin与私有保存Operit Android 端以 GitHubOAuthCoordinator.kt 作为应用自有协调入口。startLogin(completionRedirectUri)先调用 broker 服务的startLogin启动交易随后立即把transactionId、deliveryCredential与expiresAt保存进GitHubAuthPreferences——这正是文档所说「Core 保持不透明交易 ID 与领取凭据在客户端私有存储中」的实现suspend fun startLogin(completionRedirectUri: String): ResultGitHubOAuthBrokerStartResponse { val transaction oauthBrokerService.startLogin(completionRedirectUri).getOrElse { error - throw error } githubAuth.saveActiveOAuthTransaction( transactionId transaction.transactionId, deliveryCredential transaction.deliveryCredential, expiresAt transaction.expiresAt ) return Result.success(transaction) }内嵌登录走专用的EMBEDDED_COMPLETION_REDIRECT_URI https://api.operit.app/oauth/github/complete即 Worker 支持的完成地址。完成验证与一次领取completeLogincompleteLogin(completionUri)完整实现了「先校验、后领取、再落库」的调用链从私有存储读取活动交易不存在则直接失败校验completionUri中的transactionId与活动交易一致不一致即拒绝——对应文档「比较返回的目标与交易 ID」按status分派complete继续denied、error或未知状态都会清除活动交易并返回失败取消/错误即销毁交易与 Worker 侧「取消与交换错误也表示为完成状态并删除交易」对应调用oauthBrokerService.claimLogin(transactionId, deliveryCredential)领取一次领取成功后把accessToken、tokenType、expiresIn、refreshToken、user、grantedScope保存进GitHubAuthPreferences然后清除活动交易。注意领取结果解析器GitHubOAuthBrokerService.kt只接受status complete并要求accessToken、tokenType、scope、user等字段非空——一次性领取的严格性在客户端也被强制校验。网络层细节GitHubOAuthBrokerService.kt 中的两个端点与文档一致POST {BROKER_BASE_URL}/oauth/github/start请求体仅携带completionRedirectUri响应返回transactionId、deliveryCredential、authorizationUrl、completionRedirectUri与expiresAtPOST {BROKER_BASE_URL}/oauth/github/claim请求体携带transactionId与deliveryCredential响应返回status、token 字段与user。BROKER_BASE_URL https://api.operit.app。全程客户端不触碰 GitHub OAuth client secret——secret 只存在于 Cloudflare Worker 侧见 github_oauth_broker/1_CloudBroker.md。Flutter 与 CLI两种浏览器自持模式Flutter市场对话框内 WebView 拦截3_FlutterAndCliLogin.md 规定 Flutter 登录保留在市场对话框内保持既有状态broker 服务已持有待领取凭据并持久化已领取的 GitHub 认证Flutter 市场对话框已拥有自己的 WebView改动后流程在市场对话框内启动 broker 交易 → 让 WebView 导航到授权页 →拦截完成 URL→ 通过 Core 领取同时移除 CLI 帮助中的过时 token-login 命令market auth login不进入 Core 命令帮助Core 不拥有浏览器交互允许用户在完成前关闭 Flutter 登录对话框Core 与客户端文档改用「应用导向」App-oriented的措辞修正此前对登录面的不精确描述。验证要求包括确认 Flutter 市场入口构造GitHubOAuthLoginDialog确认 CLI 只拦截market auth login且不启动浏览器进程以及全树搜索已移除的 token-login 帮助与 callback-host 措辞。CLIloopback 监听与终端打印CLI 登录固定在market auth login中预留临时 loopback 端口 → 打印授权 URL 供用户自行打开 → 等待回调 → 领取。旧版 CLI 使用 GitHub Device Flow 并要求设置 GitHub OAuth client ID 环境变量见 3_Operit2Client.md新版改为调用 Core 的类型化GitHubOAuthBrokerService——Flutter 使用生成的 Dart proxy、CLI 使用生成的 Rust proxy两者都不再传递市场认证命令字符串、不解析命令 stdout、也不手写 CoreLink 请求。Android 端存在与之平行的 loopback 实现从源码结构看GitHubOAuthLoopbackCallbackServer.kt 与 GitHubOAuthBrowserSession.kt 分别承担监听器与浏览器会话管理配套文档 github_login_browser_choice_20260801/01-browser-choice-and-callback.md 进一步说明外部浏览器路径下应用先监听127.0.0.1随机端口上的/oauth/github/complete再把该地址注册为事务完成地址监听器、活动事务与浏览器窗口在取消、超时或完成后统一释放。职责边界一览谁持有什么职责归属说明OAuth client secret、PKCE、GitHub 回调交换Workersecret 只存在于 Cloudflare secret不出现在任何客户端待领取凭据、校验、一次领取、持久化认证Core broker 服务交易 ID 与 delivery credential 存于客户端私有存储浏览器呈现、完成 URL 捕获、导航拦截应用Flutter 对话框 / CLI / Android各自准备允许的回调目标只接受导航到该目标完成重定向参数Worker仅transactionId与statuscomplete不含 token 与凭据完成状态轮询无Worker 在成功领取时删除交易不提供轮询端点验证方法与改造自检仓库中给出的验证步骤见 2_AppOwnedCoordination.md 与 3_FlutterAndCliLogin.md全树搜索在 Operit2 源码树中搜索已移除的 Host API 名称BrowserCallbackHost及其传输类型确认无残留引用CLI 测试入口cargo test --manifest-path apps/cli/Cargo.toml oauth_callback可触达 CLI 包但该包当前因无关的 Runtime Host Interaction 导入、过时的setPermissionRequester调用与非SendTUI 任务而在测试执行前失败且没有任何诊断指向本次改动的 OAuth 回调文件Flutter 入口确认市场入口构造GitHubOAuthLoginDialogCLI 行为确认只拦截market auth login且不启动浏览器进程语言清理搜索源码树中已移除的 token-login 帮助与 callback-host 措辞。部署顺序见 index.md先应用 Worker D1 迁移再部署 Worker最后在应用自有完成流程可用后发布客户端。总结「App-Owned OAuth Coordination」的实质是把浏览器回调从 Host 能力还原为应用自有交互operit-host-api不再承载BrowserCallbackHostCore 只负责交易与凭据的一次性领取而 Flutter、CLI 与 Android 各自拥有自己的浏览器呈现与完成检测。完成 URL 自始至终不含 token 与领取凭据领取成功即删除交易、无轮询端点从协议到 Android 客户端源码GitHubOAuthBrokerService.kt、GitHubOAuthCoordinator.kt都贯彻了同一套「先校验、后领取、一次生效」的边界纪律。赞分享AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载相关推荐OneUptime 自托管部署 Slack 集成完整指南从应用清单生成到回调安全OneUptime 自托管部署 Slack 集成完整指南从应用清单生成到回调安全 导读 本文面向自托管部署 OneUptime 的运维与开发者完整讲解如何将可观测性后端运维前端云原生微服务AI AgentVisdom 回调事件往返链路解析从浏览器交互到 Python 回调的完整路由指南Visdom 回调事件往返链路解析从浏览器交互到 Python 回调的完整路由指南 本文是 Visdom 回调Callback与事件往返Event Ro数据可视化前端OneUptime 自托管 Slack 集成完全指南配置、回调路由与网络安全OneUptime 自托管 Slack 集成完全指南配置、回调路由与网络安全 将自托管 OneUptime 项目与 Slack 打通即可在监控告警、事件I可观测性后端运维前端云原生微服务AI Agent上一篇Windows用户必看dotnet-core-uninstall在Windows系统上的安装与配置完整教程下一篇告别加载白屏vant-weapp组件与本地存储的完美协作方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Operit GitHub OAuth 应用自有完成回调协调方案：从 Host 回调托管到应用自持的浏览器完成链路
AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载导读本文基于 Operit 仓库中 github_oauth_completion_delivery 系列设计文档系统讲解「GitHub OAuth 完成回调Completion URL由应用自身持有与协调」的落地改造为何要把浏览器回调注册与导航处理从operit-host-apiHost API中移除、Core 在待领取凭据与一次性领取中承担何种职责、Flutter 市场对话框与 Rust CLI 如何各自完成浏览器展示与完成 URL 捕获以及该改造在 Operit Android 端的源码级实现。读完本文你将掌握 OAuth 完成回调的职责边界划分、一次领取one-time claim协议的调用链以及 Flutter/CLI/Android 三类登录面的应用自有协调模式。背景被伪装成 Host 能力的应用交互未发布实现的问题在本次改造之前仓库中存在一套**未发布unshipped**的实现它把通用的浏览器回调注册generic browser callback registration与导航处理navigation handling放进了operit-host-api中同时 Flutter 侧的运行时浏览器注册表runtime browser registry也承担了同样的回调逻辑。从职责划分看这带来了一个架构性偏差浏览器回调托管本应是应用App交互的一部分却被打扮成了 Core Host 的通用能力。具体表现为浏览器完成地址的注册、导航的捕获与中转被耦合进 Host API 层任何需要 OAuth 登录的应用都必须依赖 Host 提供的回调托管Flutter 的浏览器注册表回调通道成为多余的第二套回调链路Core 的职责边界被稀释——它既要维护待领取凭据又间接参与了浏览器呈现。改造方向把浏览器呈现还给应用2_AppOwnedCoordination.md 明确列出了四项核心改动移除operit-host-api中的BrowserCallbackHost及其传输类型transport types保留Core 的 broker 服务职责维护待领取凭据pending credentials、校验、一次性领取one-time claim以及已持久化的 GitHub 认证Flutter 市场对话框自己呈现授权页并把捕获到的完成 URL 交给 CoreCLI自己预留 loopback 监听器、打印授权 URL、等待回调再把完成 URL 交给 Core。此外还要移除 Flutter 未使用的浏览器注册表回调通道unused Flutter browser-registry callback channel。从源码结构看这一改造把「浏览器呈现 完成检测」两个职责彻底划给了应用层而 Core 退回到纯粹的交易与凭据管理角色——这与配套文档 1_Protocol.md 中「每个应用拥有自己的浏览器呈现与完成检测」的协议定位完全一致。完成协议Worker 创建、应用交付、Core 一次领取交易的创建与完成重定向协议侧的完整设计见 1_Protocol.mdWorker 创建一个awaiting_callback交易transaction交易内包含PKCE verifier、经过哈希的一次性领取凭据hashed one-time delivery credential以及一个经过校验的完成重定向 URLvalidated completion redirect URLGitHub 回调 Worker 后Worker 完成授权码交换code exchange与载荷加密payload encryption然后仅以transactionId与statuscomplete两个参数重定向浏览器取消与交换错误同样以完成状态completion statuses表示并且交易会被删除完成 URL 从不携带 GitHub token 或领取凭据应用在 Worker 交易开始前就准备好允许的回调目标allowed callback destination呈现授权 URL只接受导航到该目标的结果并把完成的 URL 返回给 Core。Core 的私有存储与一次性领取应用在 Core 启动交易之前准备目标地址Core 把不透明的交易 ID 与领取凭据保存在**客户端私有存储client-private storage**中随后对比返回的完成目标destination与交易 ID匹配后才调用POST /oauth/github/claimWorker 在成功领取时删除交易因此不存在任何完成轮询端点no completion polling endpoint exists。这套设计同时解决了两个实际问题见 index.md旧的 broker 客户端在用户授权期间反复调用 Worker把空闲授权时间放大成了请求与 D1 读取量改为「Worker 存储加密结果后只投递一次不透明完成 URL」后客户端 Core 保持领取凭据私密、校验返回的交易 ID 与回调目标、并只领取一次。Android 端源码印证Core 协调器的两次调用启动交易startLogin与私有保存Operit Android 端以 GitHubOAuthCoordinator.kt 作为应用自有协调入口。startLogin(completionRedirectUri)先调用 broker 服务的startLogin启动交易随后立即把transactionId、deliveryCredential与expiresAt保存进GitHubAuthPreferences——这正是文档所说「Core 保持不透明交易 ID 与领取凭据在客户端私有存储中」的实现suspend fun startLogin(completionRedirectUri: String): ResultGitHubOAuthBrokerStartResponse { val transaction oauthBrokerService.startLogin(completionRedirectUri).getOrElse { error - throw error } githubAuth.saveActiveOAuthTransaction( transactionId transaction.transactionId, deliveryCredential transaction.deliveryCredential, expiresAt transaction.expiresAt ) return Result.success(transaction) }内嵌登录走专用的EMBEDDED_COMPLETION_REDIRECT_URI https://api.operit.app/oauth/github/complete即 Worker 支持的完成地址。完成验证与一次领取completeLogincompleteLogin(completionUri)完整实现了「先校验、后领取、再落库」的调用链从私有存储读取活动交易不存在则直接失败校验completionUri中的transactionId与活动交易一致不一致即拒绝——对应文档「比较返回的目标与交易 ID」按status分派complete继续denied、error或未知状态都会清除活动交易并返回失败取消/错误即销毁交易与 Worker 侧「取消与交换错误也表示为完成状态并删除交易」对应调用oauthBrokerService.claimLogin(transactionId, deliveryCredential)领取一次领取成功后把accessToken、tokenType、expiresIn、refreshToken、user、grantedScope保存进GitHubAuthPreferences然后清除活动交易。注意领取结果解析器GitHubOAuthBrokerService.kt只接受status complete并要求accessToken、tokenType、scope、user等字段非空——一次性领取的严格性在客户端也被强制校验。网络层细节GitHubOAuthBrokerService.kt 中的两个端点与文档一致POST {BROKER_BASE_URL}/oauth/github/start请求体仅携带completionRedirectUri响应返回transactionId、deliveryCredential、authorizationUrl、completionRedirectUri与expiresAtPOST {BROKER_BASE_URL}/oauth/github/claim请求体携带transactionId与deliveryCredential响应返回status、token 字段与user。BROKER_BASE_URL https://api.operit.app。全程客户端不触碰 GitHub OAuth client secret——secret 只存在于 Cloudflare Worker 侧见 github_oauth_broker/1_CloudBroker.md。Flutter 与 CLI两种浏览器自持模式Flutter市场对话框内 WebView 拦截3_FlutterAndCliLogin.md 规定 Flutter 登录保留在市场对话框内保持既有状态broker 服务已持有待领取凭据并持久化已领取的 GitHub 认证Flutter 市场对话框已拥有自己的 WebView改动后流程在市场对话框内启动 broker 交易 → 让 WebView 导航到授权页 →拦截完成 URL→ 通过 Core 领取同时移除 CLI 帮助中的过时 token-login 命令market auth login不进入 Core 命令帮助Core 不拥有浏览器交互允许用户在完成前关闭 Flutter 登录对话框Core 与客户端文档改用「应用导向」App-oriented的措辞修正此前对登录面的不精确描述。验证要求包括确认 Flutter 市场入口构造GitHubOAuthLoginDialog确认 CLI 只拦截market auth login且不启动浏览器进程以及全树搜索已移除的 token-login 帮助与 callback-host 措辞。CLIloopback 监听与终端打印CLI 登录固定在market auth login中预留临时 loopback 端口 → 打印授权 URL 供用户自行打开 → 等待回调 → 领取。旧版 CLI 使用 GitHub Device Flow 并要求设置 GitHub OAuth client ID 环境变量见 3_Operit2Client.md新版改为调用 Core 的类型化GitHubOAuthBrokerService——Flutter 使用生成的 Dart proxy、CLI 使用生成的 Rust proxy两者都不再传递市场认证命令字符串、不解析命令 stdout、也不手写 CoreLink 请求。Android 端存在与之平行的 loopback 实现从源码结构看GitHubOAuthLoopbackCallbackServer.kt 与 GitHubOAuthBrowserSession.kt 分别承担监听器与浏览器会话管理配套文档 github_login_browser_choice_20260801/01-browser-choice-and-callback.md 进一步说明外部浏览器路径下应用先监听127.0.0.1随机端口上的/oauth/github/complete再把该地址注册为事务完成地址监听器、活动事务与浏览器窗口在取消、超时或完成后统一释放。职责边界一览谁持有什么职责归属说明OAuth client secret、PKCE、GitHub 回调交换Workersecret 只存在于 Cloudflare secret不出现在任何客户端待领取凭据、校验、一次领取、持久化认证Core broker 服务交易 ID 与 delivery credential 存于客户端私有存储浏览器呈现、完成 URL 捕获、导航拦截应用Flutter 对话框 / CLI / Android各自准备允许的回调目标只接受导航到该目标完成重定向参数Worker仅transactionId与statuscomplete不含 token 与凭据完成状态轮询无Worker 在成功领取时删除交易不提供轮询端点验证方法与改造自检仓库中给出的验证步骤见 2_AppOwnedCoordination.md 与 3_FlutterAndCliLogin.md全树搜索在 Operit2 源码树中搜索已移除的 Host API 名称BrowserCallbackHost及其传输类型确认无残留引用CLI 测试入口cargo test --manifest-path apps/cli/Cargo.toml oauth_callback可触达 CLI 包但该包当前因无关的 Runtime Host Interaction 导入、过时的setPermissionRequester调用与非SendTUI 任务而在测试执行前失败且没有任何诊断指向本次改动的 OAuth 回调文件Flutter 入口确认市场入口构造GitHubOAuthLoginDialogCLI 行为确认只拦截market auth login且不启动浏览器进程语言清理搜索源码树中已移除的 token-login 帮助与 callback-host 措辞。部署顺序见 index.md先应用 Worker D1 迁移再部署 Worker最后在应用自有完成流程可用后发布客户端。总结「App-Owned OAuth Coordination」的实质是把浏览器回调从 Host 能力还原为应用自有交互operit-host-api不再承载BrowserCallbackHostCore 只负责交易与凭据的一次性领取而 Flutter、CLI 与 Android 各自拥有自己的浏览器呈现与完成检测。完成 URL 自始至终不含 token 与领取凭据领取成功即删除交易、无轮询端点从协议到 Android 客户端源码GitHubOAuthBrokerService.kt、GitHubOAuthCoordinator.kt都贯彻了同一套「先校验、后领取、一次生效」的边界纪律。赞分享AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载相关推荐OneUptime 自托管部署 Slack 集成完整指南从应用清单生成到回调安全OneUptime 自托管部署 Slack 集成完整指南从应用清单生成到回调安全 导读 本文面向自托管部署 OneUptime 的运维与开发者完整讲解如何将可观测性后端运维前端云原生微服务AI AgentVisdom 回调事件往返链路解析从浏览器交互到 Python 回调的完整路由指南Visdom 回调事件往返链路解析从浏览器交互到 Python 回调的完整路由指南 本文是 Visdom 回调Callback与事件往返Event Ro数据可视化前端OneUptime 自托管 Slack 集成完全指南配置、回调路由与网络安全OneUptime 自托管 Slack 集成完全指南配置、回调路由与网络安全 将自托管 OneUptime 项目与 Slack 打通即可在监控告警、事件I可观测性后端运维前端云原生微服务AI Agent上一篇Windows用户必看dotnet-core-uninstall在Windows系统上的安装与配置完整教程下一篇告别加载白屏vant-weapp组件与本地存储的完美协作方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考