Bangumi 是怎么把你登上去的？一文看懂 OAuth 2.0 登录与 Token 的完整生命周期

Bangumi 是怎么把你登上去的一文看懂 OAuth 2.0 登录与 Token 的完整生命周期【免费下载链接】Bangumi:electron: An unofficial https://bgm.tv ui first app client for Android and iOS, built with React Native. 一个无广告、以爱好为驱动、不以盈利为目的、专门做 ACG 的类似豆瓣的追番记录bgm.tv 第三方客户端。为移动端重新设计内置大量加强的网页端难以实现的功能且提供了相当的自定义选项。 目前已适配 iOS / Android。项目地址: https://gitcode.com/GitHub_Trending/ba/Bangumi你有没有好奇过Bangumi 客户端是怎么拿到你在 bgm.tv 的身份的这篇文章跟着一次 OAuth 2.0 登录走完全程第一次启动时用授权码换 Token、Token 存到本地、7 天有效期、过期后后台悄悄续票最后登出时把痕迹清零。适合想弄清 Bangumi 客户端登录实现和 Token 过期处理的同学。① 第一次打开App 怎么验明正身在登录页输入账号密码后服务器不会直接把账号的钥匙交给你而是先发一张一次性的授权码code客户端拿它去/oauth/access_token接口才换回真正的凭证。这么绕一圈是因为 code 只能用一次就算在半路被截走也没用。换票逻辑写在 src/stores/user/action.tsmethod: post, url: ${HOST}/oauth/access_token, data: urlStringify({ grant_type: authorization_code, client_id: APP_ID, client_secret: APP_SECRET, code, redirect_uri: URL_OAUTH_REDIRECT, state: getTimestamp() })state是请求那一刻生成的时间戳。服务器返回 code 时会把它带回来客户端核对一致才收下防止有人伪造页面骗你提交手里的码这是防 CSRF跨站请求伪造即攻击者冒充你发请求的常规动作。如果服务器没返回 200直接抛异常交给第④章的容错逻辑处理。② 凭证住哪儿Token 存在本地哪里、几天作废 拿到 token 后它就像一张游乐园门票平时不用但口袋里装着刷闸机就不需要再刷身份证。这张票的结构很直白export const INIT_ACCESS_TOKEN { access_token: , // 真正的凭证 expires_in: 604800, // 7 天单位秒 token_type: Bearer, scope: null, user_id: 0, refresh_token: }结构定义在 src/stores/user/init.ts。换票成功后updateAccessToken把这个对象写进用户 store并立刻持久化到本地存储。所以你把 App 杀掉再打开票还在口袋里不用重新登录。7 天有效期是关键expires_in的 604800 秒正好一周。客户端不需要每次启动都急着确认我是不是过期了只要发现数据请求因 token 过期被拒就悄悄走一次重新授权换张新票。③ 日常使用请求怎么自动带上身份登没登录是怎么判断的客户端不用一个标记来判断登录src/stores/user/computed.ts 里有三个独立的检查isLoginAPI token 是否为空决定能不能调数据接口是最基础的一道。isWebLogin网页 cookie 是否在。客户端不少功能在抓 bgm.tv 的网页走的是 cookie。过期判断拿 token 的签发时间对比 7 天有效期快到期就不让你重输密码而是触发后台重新授权换新票。浏览器版WEB里前两项恒为 false因为网页版没有本地登录流程用户是自己在设置里填 token 的。Token 是怎么塞进每个请求的你不需要在每次请求前手动贴 tokensrc/utils/fetch/fetch.ts 在发请求前统一做了一步if (accessToken.access_token) { config.headers.Authorization ${accessToken.token_type} ${accessToken.access_token} }效果是业务代码只管正常调 fetch身份自动跟着走。浏览器版有条特殊规则请求新版 API 时不带 token只打一条日志因为网页版和移动端的鉴权通道不一样旧版 APIAPI_V0不受影响。④ 出岔子时网络抖动、重新授权失败怎么办网络不会永远稳定授权链路又长失败是常事。客户端不会失败一次就放弃但也不会无限重试——它设置了明确上限。登录页维护着一个重试计数器_retryCount上限由 src/screens/login/v2/index.tsx 里的常量AUTH_RETRY_COUNT定义。授权 → 拿 code → 换票整个链路每抛一次错计数就加一达到上限后停下来提示登录失败请重试或重启客户端而不是干转到天荒地老。后台重新授权token 过期时悄悄换新票也有兜底服务器返回 4xx说明 cookie 本身已经失效提示重新授权失败请重新登录网络抖动则提示请检查网络后重试。还有个容易忽略的细节重新授权开始时弹出的正在重新授权loading在失败路径里也保证会被收掉不会永远挂在界面上。⑤ 收尾登出为什么要把痕迹清零 登出时最简单的做法是删掉 token。但登录状态其实散在好几处API token、网页 cookie、用户资料、过期标记漏掉任何一处重新登录后都可能混进别人的内容。登出逻辑分两步做先把这些字段一次性重置为初始值再逐个调用save覆盖本地存储——光在内存里清掉不够必须落盘否则下次启动旧票又复活。为什么还要用setTimeout(..., 0)把重置推迟到下一个事件循环因为登出触发时可能还有请求在途。同步清空会出现同一拍里一半新一半旧的状态后面的代码可能把半清的数据又写回存储。延迟一拍时序上就变成要么全旧、要么全新没有暧昧窗口。这样一次登录的一生就走完了第一次启动换出 7 天门票、存进本地、跟着每个请求自动出示、过期时悄悄换新、出岔子时有限重试兜底、登出时把盘清干净。想自己翻源码的话建议按这个顺序看src/stores/user/init.tstoken 与用户状态的初始结构src/stores/user/action.ts换票、重新授权、登出src/stores/user/computed.ts登录状态的三重判断src/utils/fetch/fetch.ts请求自动带身份的那一步【免费下载链接】Bangumi:electron: An unofficial https://bgm.tv ui first app client for Android and iOS, built with React Native. 一个无广告、以爱好为驱动、不以盈利为目的、专门做 ACG 的类似豆瓣的追番记录bgm.tv 第三方客户端。为移动端重新设计内置大量加强的网页端难以实现的功能且提供了相当的自定义选项。 目前已适配 iOS / Android。项目地址: https://gitcode.com/GitHub_Trending/ba/Bangumi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考