Civitai 主应用鉴权切换实战从 NextAuth 到中心化薄会话Thin-SessionHub 的完整迁移【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文基于仓库内的 main-app-auth-cutover.md 一文系统讲解 Civitai 主应用Next.js如何把认证体系从 NextAuth 完全切换到中心化认证 Hubapps/auth包括服务端会话解析的三级回退、薄 JWTciv-token的本地验签与滚动续期、会话字段契约对齐、设备级多账号切换、旧 Cookie 静默升级以及删除 NextAuth的五阶段拆除计划与STEP-H-REMOVAL追踪机制。读完你可以掌握一条完整的单点认证中心 无状态消费端架构落地路径并能对照当前源码验证迁移的最终状态。1. 背景、规模与切换的最终状态这份文档是薄会话迁移thin-session migration中主应用侧的记录完整设计见 thin-session-token-design.md。核心模型一句话概括Hubapps/auth是唯一的会话数据生产者producer 令牌签发者issuer主应用退化为纯消费者consumer——读 Cookie → 本地验签 → 通过civitai/auth包的createSessionClient解析出用户。这次切换触及的是安全关键路径文档原文给出了量化规模——24 个服务端鉴权入口 约 317 个客户端useCurrentUser调用点。需要特别注意文档头部的状态声明该文目前标记为SUPERSEDED / HISTORICAL——迁移已上线文中描述的 swap-token 桥与USE_HUB_SESSION开关连同produceFallback、sync.ts等均已被移除跨域登录现在是OAuth 授权码 PKCE 的第一方桥当前状态应参考 spoke-integration-guide.md 与 auth-hub-spoke-overview.md。因此本文按历史过程 当前源码落点两个视角来组织文档记录的是如何一步步走过去而当前代码src/server/auth/、src/pages/api/auth/印证了走到哪一步、哪些被拆除。文档中 2026-06-17 的更新记录确认了拆除的最后一步Phase 4–5在该分支完成[...nextauth].ts、next-auth-options.ts、token-refresh.ts已删除SessionProvider.tsx成为next-auth/react的第一方替代品next-auth已从根package.json移除。这一点与当前仓库目录一致——src/pages/api/auth/ 下已不存在[...nextauth].ts、sync.ts和civ-token.ts。2. 为什么最初采用开关门控以及切换前置条件文档专门解释了这次切换为什么在最初是以 flag 门控方式推进的NextAuth 是安全关键的认证热路径而切换有一个硬性前置条件——在该环境中 Hub 必须已经是生产者 登录权威已部署、正在签发会话 Cookie、/api/auth/identity可用且主应用的环境变量AUTH_JWT_ISSUER外加AUTH_JWKS_URI或AUTH_JWT_PUBLIC_KEY已指向它。由于当时开发环境尚未满足该前置条件实现上把新路径放在USE_HUB_SESSION默认false之后NextAuth 作为字节级一致的兜底开关关闭时getServerAuthSession的代码分支插在 bearer-token 块之后、next-auth 块之前关闭路径与旧代码完全等价运行中的应用和存量会话不受任何影响可以在翻开关前充分审查。这套灰度门控的做法对任何安全关键路径的替换都有参考价值先加旁路、保证关闭态零差异、满足前置条件后再切换、最后拆旁路。3. 服务端会话解析getServerAuthSession的完整回退链当前实现位于 get-server-auth-session.ts其解析顺序L58–L115是文档所述方案收敛后的最终形态请求级缓存req.context.session已存在则直接复用同一请求内 tRPC/API 多次调用不重复解析。Bearer Token / API Key 路径从Authorization头或?token查询参数显式排除WEBHOOK_TOKEN取令牌走 bearer-token.ts 的getSessionFromBearerToken。文档特别强调此路径在迁移中零改动——它通过getSessionUser({ userId })读取的是与 Hub 共享的同一份session:data2缓存Hub 的产出缓存未命中时本地计算因此迁移期间天然兼容。命中后还会把tokenScope、buzzLimit、apiKeyId、subject一并挂到req.context。Hub 薄会话civ-tokengetHubSession(req)走本地验签 → 共享缓存 → Hub/api/auth/identity链路成功则缓存进req.context.session并顺带调用maybeRollHubCookie做滚动续期见第 6 节。遗留 NextAuth Cookiecivitai-token/ 生产环境__Secure-civitai-token只读解码。这是五阶段中Legacy decoder阶段的产物——用civitai/auth的decodeLegacySessionCookie做jose 解码不再依赖 next-auth取出sub/user.id后调sessionClient.getSessionUserById(userId)解析出新鲜的会话用户同样命中共享缓存或 Hub。Cookie 名用与 Hub Cookie 相同的 dev/prod secure 逻辑解析保证生产环境读的是__Secure-变体。其中有一个仅 PREVIEW 环境的兜底L42–L54PR 预览部署跑在 dev 库克隆上冒烟用户只在克隆里有、Hub 里没有对应行于是信任 Cookie 内嵌的user对象。该分支被IS_PREVIEW门控生产环境永远不会信任内嵌用户必须经 Hub 解析因此零生产影响面。读时升级upgrade-on-read本次请求若最终从遗留 Cookie 解析成功会先打点observeLegacyDecode()在升级尝试之前计数以便区分没有遗留 Cookie 了与这段代码根本没跑过再尽力而为地把该用户迁移到civ-token见第 9 节。失败语义Hub 路径与遗留路径都用.catch(() null)包裹——任何异常都表现为未登录而不是 500即文档中fails closed tonull的落实。4. 消费端解析器createSessionClient与共享缓存链路主应用侧的解析器封装在 session-client.ts文件头注释直接点明其身份主应用访问中心化认证 Hub 的句柄薄会话模型——docs/main-app-auth-cutover.md。export const sessionClient createSessionClient({ isRevoked, // 注入共享 redis 的 TOKEN_STATE 吊销检查 onIdentityLeg: (outcome, durationSeconds) observeSessionLeg(identity, outcome, durationSeconds), onJwksLeg: (outcome, durationSeconds) observeSessionLeg(jwks, outcome, durationSeconds), onIdentityByIdLeg: /* API-key/OAuth by-id 读路径打点 */, onHubWriteLeg: /* Hub 写路径打点 */, });isRevoked注入是关键安全细节L15–L16 注释富用户对象来自共享缓存而非令牌本身若不注入吊销检查一个已登出/封禁的civ-token会在session:data2缓存命中时持续解析成功直到缓存重新预热。注入后读路径在验签 过期检查之外缓存命中前就会拒绝被吊销令牌。该检查内部 fail-open——redis 抖动不能把所有人登出。遥测回调onIdentityLeg等用于在主应用侧对身份读取一跳JWKS 验签一跳计时——因为这一跳是主应用→Hub 的 hairpinHub 自己的 metrics 看不到它。包保持零基础设施依赖不引 prom-client由调用方接线到 prom-client。而真正的解析链在包实现 packages/civitai-auth/src/session-client.ts 中getSessionUserL110–L154本地验签jose 校验签名 过期iss按配置校验再执行注入的isRevoked。验证令牌不需要任何对 Hub 的调用。共享缓存读取session:data2:{userId}fail-open缓存抖动直接落到 Hub 拉取而不抛错。未命中时拉取 Hub/api/auth/identity且带三重工程保护防伪造发行者trustedHubBaseL262–L282令牌iss的 origin 必须与配置里的AUTH_JWT_ISSUER/AUTH_JWKS_URIorigin 匹配否则 fail closed 不发起请求——session 令牌作为 Bearer 发往的域名永远只能是运维配置过的 Hub绝不可能被攻击者控制的iss指向任意源。集群内路由当配置了AUTH_HUB_INTERNAL_URL时验证仍对照公网iss但实际身份一跳走集群内 Hub 服务地址消除应用→Cloudflare→Traefik→同一集群的 hairpin 单点一次 CF 边缘抖动曾造成过全集群级认证卡顿。1.5 秒超时 每 Pod 单飞single-flightAbortSignal.timeout(1500)保证半开连接不会把认证请求挂到 TCP keepaliveinflightMap 把同一用户的并发缓存未命中合并成一次 Hub 请求防止缓存击穿时 N 个并发请求扇出成 N 次相同 HTTP 调用stampede 保护。刷新/失效不需要主应用做任何改动——这是文档中一个容易被忽略但很妙的结论主应用与 Hub共享同一份 redis既有的refreshSession/invalidateSession/invalidateAllSessions本来就通过clearSessionCache/clearCacheByPattern清除session:data2:{userId}Hub 下次读时重新生产因此刷新/失效自动传播给所有消费者。若改走sessionClient.invalidate只是多一次冗余的 HTTP 跳。逐令牌的TOKEN_STATE标记与SessionRefresh实时信号保持不变——那是登出/实时通知机制与数据刷新正交。getHubSession本身L40–L54是一个薄包装读sessionCookieName()对应的 Cookie →sessionClient.getSessionUser(token)→ 顺带从已验签令牌里解码impersonatedByclaim模拟登录场景见第 8 节→ 以as Session返回。5. 会话用户形状对齐文档 D 节Hub 生产的civitai/authSessionUser与主应用历史的ExtendedUser契约达到全字段对齐无字段省略。其中四个历史上缺失的纯客户端字段——name、autoplayGifs、leaderboardShowcase、referral——后来补进了包契约 Hub 生产者查询含UserReferraljoinshapeSessionUser。由于包的SessionUser对tier/meta/banDetails/subscriptions仍采用宽松类型widened边界处保留了as unknown as Session的类型转换。allowAds/redBrowsingLevel改为从用户的持久化User.settings计算尊重显式值否则取基于 tier 的默认值并被缓存而不是硬编码。该逻辑位于 Hub 生产者 session-shape.ts。文档还保留了一条刻意留存的 parity 差异供评审Hub 对这两个字段采用聚焦解析lenient focused parse而旧路径getSessionUser跑完整的userSettingsSchema.safeParse——后者在 settings blob 里任何无关字段类型错误时整体失败并全部回落默认值。因此对于settings 里有无关坏字段且显式设置了allowAds/redBrowsingLevel的用户Hub 会尊重显式值而旧路径给默认值。要逐位对齐需让getSessionUser也采用聚焦读法——这是一个与收入相邻的变更显式设置allowAdsfalse的用户才真正看不到广告文档作者选择留给显式审批而不单方面改变主应用行为。这条注释展示了迁移中形状对齐与行为对齐是两个不同层次的问题。客户端侧形状src/pages/api/auth/session.ts 是第一方SessionProvider/useSession以及全部约 317 个useCurrentUser调用点轮询的端点返回{ user, expires }形状无会话时返回200 空对象{}而非 401——遵循 next-auth 的既有约定客户端无需感知后端已换代薄会话不向客户端暴露真实的expires端点合成一个 30 天后的时间戳——真正的生命周期由 Cookie maxAge Hub 的吊销标记掌控。SSR 初始会话经由/api/user/settings走同一服务端解析自动保持一致。6. 会话生命周期活动驱动的滚动续期文档 C 节next-auth 时代 JWT 会在活动时被滚动updateAge约 24h活跃用户永不过期。薄civ-token是登录起算的固定窗口因此需要复刻滚动语义Hub 侧POST /api/auth/refreshapps/auth/src/routes/api/auth/refresh/server.ts先验证提交上来的civ-token仍然有效签名 过期 吊销然后为同一用户、同一jti签发一枚新令牌新的 signedAt/exp——延长窗口但不改变会话身份过期/被吊销的令牌直接拒绝→ 重新登录。只有 Hub 能签发主应用是 verify-only。主应用侧maybeRollHubCookiesrc/server/auth/session-client.ts#L70-L89 在每次服务端会话解析成功后执行解码令牌iat若年龄超过AUTH_SESSION_UPDATE_AGE默认24h文档建议后续上调至约 7 天经包内sessionTokenClient.refresh(token, { deviceCookie })带 2.5s 超时向 Hub 换新令牌并通过setSessionCookie在响应上同时重置civ-token与设备 Cookie两者都是最近活动起 30 滚动天。该实现有两条工程约束值得注意源码注释原文提炼best-effort fire-safe任何失败都保留当前仍有效的令牌用户保持登录下次请求重试每次 updateAge 跨越最多触发一次重置 Cookie 即重置了时钟且刷新保持jti不变区别于第 9 节的升级路径——升级会铸造新jti所以需要额外的去重锁。无需任何客户端接线——主应用本就可以设置.civitai.com域 Cookie。7. 设备级多账号切换文档 E 节这是整个 cutover 中最复杂的一块。设计要点设备级device-level而非客户端凭证或 DB 级账号关联——Hub 为每个浏览器维护一个设备集合httpOnlyciv-deviceCookie → Redis hashdevice:accounts:{deviceId}内容为userId → lastSwitchedAt30 天滚动与会话一致登录 切换 滚动续期都会刷新。一次切换的授权 当前活跃会话 目标账号在本设备集合内且新鲜30 天。localStorage里零凭证仅展示用。Hub 侧实现device.ts设备 Cookie Redis 集合link/list/isFresh/remove 30 天剪枝、POST /api/auth/switchapps/auth/src/routes/api/auth/switch/server.ts、GET /api/auth/accountsapps/auth/src/routes/api/auth/accounts/server.ts登录时establishSession → touchAccount自动关联账号。主应用侧同源代理因为.red等站点跨站部署、无法直接用包内浏览器客户端/api/auth/accounts代理GET 列表 DELETE ?userId移除、/api/auth/switch代理转发 → 设置 civ-token → 滚动设备 Cookie以及AccountProvider重写从 Hub 设备集合取列表、swapAccount切换、只登出单个账号而不切换、removeAccount。遗留数据保护切换器把 Hub 设备集合与既有的civitai-accountslocalStorage合并用户在切换过程中不丢任何已关联账号切换到仅存在于 legacy 的条目时在 Hub 侧兑换其存储的令牌同时把该账号关联进设备集合迁移完成后条目从 localStorage 剪除新关联永不写 localStorage。文档列出的剩余项logoutAll登出本设备全部账号需要 Hub 提供忘记本设备账号集合调用——清除 Redis 集合 吊销本设备关联会话且不得影响同用户其他设备与**在所有设备登出**账户页动作走注册表的按用户截止invalidateUserSessions与设备级logoutAll语义完全不同。跨域交换历史实现现已移除文档详细记录了基于顶层导航的SameSiteLax安全流程带凭证的 fetch 无法跨站携带 Hub Cookiespoke/api/auth/sync→ 顶层重定向到 Hub/api/auth/sync?callback…returnUrl…→ Hub 读自己的 Lax Cookie、铸造一次性swap 令牌 → 回跳 spoke → spoke 服务端到服务端POST /api/auth/exchange兑换swap 令牌本身即凭证→ 设置本域 Cookie。一次性由verifySwapToken暴露的jti HubsetNX烧录swap:used:{jti} TTL保证被从重定向 URL 截获的令牌无法重放。该桥现已删除跨域登录改走 OAuth 授权码 PKCE 第一方桥——对照当前 spoke-integration-guide.md。架构规则适用于所有 spoke→Hub 调用不允许手搓 Hub 调用。所有请求必须经过civitai/auth助手应用代码永远不内联 Hub URL/契约。当时的助手面createSessionClient令牌→用户 服务级 invalidate/refresh、createDeviceAccountClient列表/切换/移除设备 Cookie 透传、createSessionTokenClient滚动刷新 吊销令牌鉴权。应用代理只做框架胶水如设置 Next 响应 Cookie。8. 审核员模拟登录文档 F 节与账号切换刻意分离授权模型不同所有权 vs 审核员特权。唯一授权门槛是请求者本人是审核员——没有内部令牌、没有额外凭证、不查所有权/设备也不得触碰设备账号集合目标不是被关联账号。HubPOST /api/auth/impersonate请求者自身会话必须是审核员唯一闸门→ 为目标铸造带impersonatedBy: modIdclaim 的薄civ-token→ 写ModActivity审计行。Hub 侧路由已就位apps/auth/src/routes/api/auth/impersonate/server.ts 与 exit/server.ts。退出模拟不再依赖localStorage的ogAccount——而是读取impersonatedByclaim 重新铸造审核员会话。这一点在当前主应用代码中已落地getHubSession 在 L50 解码impersonatedBy——claim 是身份性的identity-only不含凭证仅用于让客户端显示退出模拟控件。文档保留的验收项impersonate → 以用户身份操作 → 退出回到审核员的 e2e 验证以及主应用impersonate.ts路由到 Hub保留禁止自我模拟的守卫。9. 遗留 Cookie 迁移从可选静默升级到读时升级文档 G 节 当前实现文档 G 节把静默升级列为可选但推荐请求带有有效 legacycivitai-token但没有civ-token时透明地在 Hub 侧铸造civ-token不经过登录界面让用户免重新登录完成迁移不做的话遗留 Cookie 也只是自然老化退出。当前源码显示该升级已实现为upgrade-on-read并针对一个真实的滥用向量做了加固maybeUpgradeLegacySessionsrc/server/auth/session-client.ts#L91-L173每枚遗留 Cookie 每窗口只升级一次而非每请求一次升级会铸造新jti若按请求触发一个不持久化Set-Cookie的客户端脚本化集成、无 Cookie 的 HTTP 客户端会无限重复铸造既无年龄门控也无限流。实现用SHA-256 指纹只存哈希不存原值指纹不是凭证作为 keysysRedis.set(key, 1, { NX: true, EX: 600 })做 10 分钟去重窗口。fail-openredis 抖动不阻断迁移退化为旧的每请求升级行为不算回归。升级流程sessionTokenClient.exchangeLegacy(legacyToken, { deviceCookie })透传已有civ-device让 Hub 复用本浏览器设备集合纯 legacy 用户则由 Hub 铸造设备 Cookie 返回——否则升级后的会话不会出现在账号切换器里→ 拿到新civ-token→setSessionCookie同步设置 civ-token 设备 Cookie → 在同一响应里clearLegacyCookies清空所有遗留 next-auth Cookie会话 CSRF/callback-url/state/PKCE 等杂项。全程 best-effortHub 抖动时遗留 Cookie 原样保留本请求已由遗留解码服务下一次请求重试。升级成功打legacy-session-upgraded日志含解析后的userId。指标侧observeLegacyDecode()独立计数遗留解码仍在发生为最终删除遗留解码路径提供依据。10. 五阶段拆除计划与STEP-H-REMOVAL追踪文档 H 节文档的核心决策是在上线前彻底移除 NextAuth而不是保留翻回 NextAuth的开关混合态。理由是翻回安全网是虚假的——用户一旦在 Hub 登录就持有civ-token把开关翻回 NextAuth 会无视该 Cookie→ 登出用户而如果 Hub 恰是故障源用户连重新登录的机会都没有。混合态的安全网每天都在缩水牺牲的却是最要紧的会话。替代方案是主应用独立于 Hub 验证会话本地验签 共享缓存因此存量会话能扛住 Hub 故障受影响的只有新登录Hub 无论如何都是登录权威用 Hub 高可用缓解。五阶段滚动每阶段保持应用可用NextAuth 活到最后一刻阶段内容1. 韧性解析本地验签 缓存 → Hub 解析链2. 遗留解码器jose解码civitai-tokengetServerAuthSession解析新/旧令牌无 NextAuth3. 账号切换 模拟登录 Hub 原生化E F见第 7、8 节4. 客户端用第一方 Provider 替换next-auth/reactSessionProvider/useSession走/api/auth/session约 317 个useCurrentUser调用点透明切换signIn/signOut本就已路由到 Hub5. 删除服务端 NextAuth[...nextauth].ts、next-auth-options、token-refresh、AES civ-token删除依赖可执行的拆除追踪机制每一个新增或依赖的 NextAuth 触点都携带STEP-H-REMOVAL:代码注释。到 Step H 时grep -rn STEP-H-REMOVAL src packages即得穷尽的移除清单目标是执行后next-auth引用归零。文档中的盘点表摘选关键行位置是什么Step-H 动作src/pages/api/auth/[...nextauth].tsNextAuth 捕获全部处理器 signIn/signOut 事件删除src/server/auth/next-auth-options.tscreateAuthOptions、jwt()/session()回调、providers、adapter、AES 账号切换、legacy JWE 编解码删除E/F 迁移到 Hub 后src/server/auth/get-server-auth-session.tslegacygetServerSession块 Session类型导入删块Session类型用第一方类型替换它是全应用的返回类型src/utils/auth-helpers.tshandleSignIn/handleSignOut中的 next-auth 兜底删兜底 导入Hub 路径保留src/components/UpdateRequiredWatcher/UpdateRequiredWatcher.tsxSESSION_REFRESH_HEADER分支调 next-authupdate()其服务端 setter 已删分支已死删该分支由信号机制session-invalidation.ts取代保留 generation-update 分支src/shared/constants/auth.constants.ts与civitai/auth重复的SESSION_REFRESH_HEADER/COOKIE 非鉴权的GENERATION_UPDATE_HEADER迁出后者删除文件src/pages/api/auth/civ-token.ts死掉的 AES civ-token 端点无调用方删除可提前于 Phase 5next-authnext-auth/react依赖全应用导入含约 317 个客户端调用点✅已完成——根应用与civitai/auth均无 next-auth 导入残留端点处置清单src/pages/api/auth/*逐文件审计——迁移只删两个其余都保留且各有理由删除civ-token.ts死端点无调用方、[...nextauth].tsPhase 5legacy 兑换 Hub 原生化后删。保留oauth/*jwks.tsOIDC 提供方Sign in with Civitaijwks.ts即其jwks_uriaccounts.ts/switch.ts/impersonate.ts主应用到 Hub 的同源代理post-login.ts在 civitai.com 上执行 Hub 够不着的登录副作用——ref_*Cookie、Tracker、referral、社区加入通知抽取为 login-side-effects.ts 的runLoginSideEffects新旧两条登录路径共用新用户/老用户由user.createdAt判定logout.ts清 civ-token 遗留civitai-token orchestrator Cookie并在 Hub 侧吊销session.ts成为第一方{ user, expires }端点freshdesk.ts独立功能user-from-token.ts集成令牌 webhook 工具仓库内无调用方但外部集成可能依赖需确认后再删。注意原清单中的sync.ts跨域登录的 swap 令牌接收端已随 swap 桥整体移除。环境/运维清单每环境AUTH_JWKS_URI、AUTH_JWT_ISSUER已设共享 redis 已确认Hub 持有 EC P-256 密钥对AUTH_JWT_PRIVATE_KEY/AUTH_JWT_PUBLIC_KEY/AUTH_JWT_KIDJWKS 对每个 spoke含 civitai.red可达。11. 切换验证流程与测试策略文档给出的如何翻开关 验证历史操作当时开关存在确认前置条件该环境的 Hub 在生产 是登录权威 环境变量就绪客户端/api/auth/session已实现——服务端与客户端约定一致设置USE_HUB_SESSIONtrue验证Hub 登录 → tRPC/API 调用中getServerAuthSession返回用户 → 客户端useCurrentUser可解析 → refresh/封禁失效传播正常。撤销开关即可瞬时回滚。测试策略的结论是分层防御getHubSession是civitai/authcreateSessionClient的薄包装解析/验签/缓存/拉取逻辑由包的 58 个单元测试覆盖见 packages/civitai-auth/src/tests/含session-client.test.ts、verify.test.ts、legacy-cookie.test.ts等主应用当时没有单元测试运行器仅 Playwright e2e因此主应用端到端路径的最佳验证方式是对一个真实生产中的 Hub 跑 e2e或者给主应用也加 vitestapps/auth已是这么做的。文档 B 节还记录了浏览器冒烟的具体走法未登录访问/generate→/login→ Hub 邮箱登录 →civ-token落定 →/api/auth/post-login副作用 → 重定向回/generate。12. 对照当前仓库文档与代码的现状核对把文档的最终声明与当前源码交叉验证可以得到一张干净的落地清单已拆除文档声明代码印证USE_HUB_SESSION开关在src/与apps/中已无任何引用src/pages/api/auth/下[...nextauth].ts、sync.ts、civ-token.ts均不存在/api/auth/session.ts已是纯第一方端点session.ts 第 4–6 行注释明确写着取代了旧 next-auth[...nextauth]的 session 路由legacyaccount-switch-hub接收端STEP-H 清理项已删。保留并长期存在jose 遗留解码器只读随旧 Cookie 老化退出、upgrade-on-read 升级路径、滚动续期maybeRollHubCookie、Session类型的第一方化get-server-auth-session.ts 顶部注释仍标记着FINAL-CLEANUPSession类型替换是next-auth依赖彻底移除的收尾项。当前跨域模型以 spoke-integration-guide.md 为准OAuth 授权码 PKCE 第一方桥swap-token 桥相关内容仅具历史价值。这份文档的价值在于它把一次大型安全关键路径替换的完整决策链留了下来为什么灰度、灰度何时失效虚假安全网论证、五阶段如何各自保持应用可用、用 grep-able 注释保证拆除穷尽性、以及每个保留/删除端点的逐条理由——这套方法论比迁移本身更值得同类改造任何从内建鉴权框架迁移到自建认证中心的项目直接借鉴。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 23:13:10 · 阅读 1.2k Civitai 主应用鉴权切换实战：从 NextAuth 到中心化薄会话（Thin-Session）Hub 的完整迁移
Civitai 主应用鉴权切换实战从 NextAuth 到中心化薄会话Thin-SessionHub 的完整迁移【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文基于仓库内的 main-app-auth-cutover.md 一文系统讲解 Civitai 主应用Next.js如何把认证体系从 NextAuth 完全切换到中心化认证 Hubapps/auth包括服务端会话解析的三级回退、薄 JWTciv-token的本地验签与滚动续期、会话字段契约对齐、设备级多账号切换、旧 Cookie 静默升级以及删除 NextAuth的五阶段拆除计划与STEP-H-REMOVAL追踪机制。读完你可以掌握一条完整的单点认证中心 无状态消费端架构落地路径并能对照当前源码验证迁移的最终状态。1. 背景、规模与切换的最终状态这份文档是薄会话迁移thin-session migration中主应用侧的记录完整设计见 thin-session-token-design.md。核心模型一句话概括Hubapps/auth是唯一的会话数据生产者producer 令牌签发者issuer主应用退化为纯消费者consumer——读 Cookie → 本地验签 → 通过civitai/auth包的createSessionClient解析出用户。这次切换触及的是安全关键路径文档原文给出了量化规模——24 个服务端鉴权入口 约 317 个客户端useCurrentUser调用点。需要特别注意文档头部的状态声明该文目前标记为SUPERSEDED / HISTORICAL——迁移已上线文中描述的 swap-token 桥与USE_HUB_SESSION开关连同produceFallback、sync.ts等均已被移除跨域登录现在是OAuth 授权码 PKCE 的第一方桥当前状态应参考 spoke-integration-guide.md 与 auth-hub-spoke-overview.md。因此本文按历史过程 当前源码落点两个视角来组织文档记录的是如何一步步走过去而当前代码src/server/auth/、src/pages/api/auth/印证了走到哪一步、哪些被拆除。文档中 2026-06-17 的更新记录确认了拆除的最后一步Phase 4–5在该分支完成[...nextauth].ts、next-auth-options.ts、token-refresh.ts已删除SessionProvider.tsx成为next-auth/react的第一方替代品next-auth已从根package.json移除。这一点与当前仓库目录一致——src/pages/api/auth/ 下已不存在[...nextauth].ts、sync.ts和civ-token.ts。2. 为什么最初采用开关门控以及切换前置条件文档专门解释了这次切换为什么在最初是以 flag 门控方式推进的NextAuth 是安全关键的认证热路径而切换有一个硬性前置条件——在该环境中 Hub 必须已经是生产者 登录权威已部署、正在签发会话 Cookie、/api/auth/identity可用且主应用的环境变量AUTH_JWT_ISSUER外加AUTH_JWKS_URI或AUTH_JWT_PUBLIC_KEY已指向它。由于当时开发环境尚未满足该前置条件实现上把新路径放在USE_HUB_SESSION默认false之后NextAuth 作为字节级一致的兜底开关关闭时getServerAuthSession的代码分支插在 bearer-token 块之后、next-auth 块之前关闭路径与旧代码完全等价运行中的应用和存量会话不受任何影响可以在翻开关前充分审查。这套灰度门控的做法对任何安全关键路径的替换都有参考价值先加旁路、保证关闭态零差异、满足前置条件后再切换、最后拆旁路。3. 服务端会话解析getServerAuthSession的完整回退链当前实现位于 get-server-auth-session.ts其解析顺序L58–L115是文档所述方案收敛后的最终形态请求级缓存req.context.session已存在则直接复用同一请求内 tRPC/API 多次调用不重复解析。Bearer Token / API Key 路径从Authorization头或?token查询参数显式排除WEBHOOK_TOKEN取令牌走 bearer-token.ts 的getSessionFromBearerToken。文档特别强调此路径在迁移中零改动——它通过getSessionUser({ userId })读取的是与 Hub 共享的同一份session:data2缓存Hub 的产出缓存未命中时本地计算因此迁移期间天然兼容。命中后还会把tokenScope、buzzLimit、apiKeyId、subject一并挂到req.context。Hub 薄会话civ-tokengetHubSession(req)走本地验签 → 共享缓存 → Hub/api/auth/identity链路成功则缓存进req.context.session并顺带调用maybeRollHubCookie做滚动续期见第 6 节。遗留 NextAuth Cookiecivitai-token/ 生产环境__Secure-civitai-token只读解码。这是五阶段中Legacy decoder阶段的产物——用civitai/auth的decodeLegacySessionCookie做jose 解码不再依赖 next-auth取出sub/user.id后调sessionClient.getSessionUserById(userId)解析出新鲜的会话用户同样命中共享缓存或 Hub。Cookie 名用与 Hub Cookie 相同的 dev/prod secure 逻辑解析保证生产环境读的是__Secure-变体。其中有一个仅 PREVIEW 环境的兜底L42–L54PR 预览部署跑在 dev 库克隆上冒烟用户只在克隆里有、Hub 里没有对应行于是信任 Cookie 内嵌的user对象。该分支被IS_PREVIEW门控生产环境永远不会信任内嵌用户必须经 Hub 解析因此零生产影响面。读时升级upgrade-on-read本次请求若最终从遗留 Cookie 解析成功会先打点observeLegacyDecode()在升级尝试之前计数以便区分没有遗留 Cookie 了与这段代码根本没跑过再尽力而为地把该用户迁移到civ-token见第 9 节。失败语义Hub 路径与遗留路径都用.catch(() null)包裹——任何异常都表现为未登录而不是 500即文档中fails closed tonull的落实。4. 消费端解析器createSessionClient与共享缓存链路主应用侧的解析器封装在 session-client.ts文件头注释直接点明其身份主应用访问中心化认证 Hub 的句柄薄会话模型——docs/main-app-auth-cutover.md。export const sessionClient createSessionClient({ isRevoked, // 注入共享 redis 的 TOKEN_STATE 吊销检查 onIdentityLeg: (outcome, durationSeconds) observeSessionLeg(identity, outcome, durationSeconds), onJwksLeg: (outcome, durationSeconds) observeSessionLeg(jwks, outcome, durationSeconds), onIdentityByIdLeg: /* API-key/OAuth by-id 读路径打点 */, onHubWriteLeg: /* Hub 写路径打点 */, });isRevoked注入是关键安全细节L15–L16 注释富用户对象来自共享缓存而非令牌本身若不注入吊销检查一个已登出/封禁的civ-token会在session:data2缓存命中时持续解析成功直到缓存重新预热。注入后读路径在验签 过期检查之外缓存命中前就会拒绝被吊销令牌。该检查内部 fail-open——redis 抖动不能把所有人登出。遥测回调onIdentityLeg等用于在主应用侧对身份读取一跳JWKS 验签一跳计时——因为这一跳是主应用→Hub 的 hairpinHub 自己的 metrics 看不到它。包保持零基础设施依赖不引 prom-client由调用方接线到 prom-client。而真正的解析链在包实现 packages/civitai-auth/src/session-client.ts 中getSessionUserL110–L154本地验签jose 校验签名 过期iss按配置校验再执行注入的isRevoked。验证令牌不需要任何对 Hub 的调用。共享缓存读取session:data2:{userId}fail-open缓存抖动直接落到 Hub 拉取而不抛错。未命中时拉取 Hub/api/auth/identity且带三重工程保护防伪造发行者trustedHubBaseL262–L282令牌iss的 origin 必须与配置里的AUTH_JWT_ISSUER/AUTH_JWKS_URIorigin 匹配否则 fail closed 不发起请求——session 令牌作为 Bearer 发往的域名永远只能是运维配置过的 Hub绝不可能被攻击者控制的iss指向任意源。集群内路由当配置了AUTH_HUB_INTERNAL_URL时验证仍对照公网iss但实际身份一跳走集群内 Hub 服务地址消除应用→Cloudflare→Traefik→同一集群的 hairpin 单点一次 CF 边缘抖动曾造成过全集群级认证卡顿。1.5 秒超时 每 Pod 单飞single-flightAbortSignal.timeout(1500)保证半开连接不会把认证请求挂到 TCP keepaliveinflightMap 把同一用户的并发缓存未命中合并成一次 Hub 请求防止缓存击穿时 N 个并发请求扇出成 N 次相同 HTTP 调用stampede 保护。刷新/失效不需要主应用做任何改动——这是文档中一个容易被忽略但很妙的结论主应用与 Hub共享同一份 redis既有的refreshSession/invalidateSession/invalidateAllSessions本来就通过clearSessionCache/clearCacheByPattern清除session:data2:{userId}Hub 下次读时重新生产因此刷新/失效自动传播给所有消费者。若改走sessionClient.invalidate只是多一次冗余的 HTTP 跳。逐令牌的TOKEN_STATE标记与SessionRefresh实时信号保持不变——那是登出/实时通知机制与数据刷新正交。getHubSession本身L40–L54是一个薄包装读sessionCookieName()对应的 Cookie →sessionClient.getSessionUser(token)→ 顺带从已验签令牌里解码impersonatedByclaim模拟登录场景见第 8 节→ 以as Session返回。5. 会话用户形状对齐文档 D 节Hub 生产的civitai/authSessionUser与主应用历史的ExtendedUser契约达到全字段对齐无字段省略。其中四个历史上缺失的纯客户端字段——name、autoplayGifs、leaderboardShowcase、referral——后来补进了包契约 Hub 生产者查询含UserReferraljoinshapeSessionUser。由于包的SessionUser对tier/meta/banDetails/subscriptions仍采用宽松类型widened边界处保留了as unknown as Session的类型转换。allowAds/redBrowsingLevel改为从用户的持久化User.settings计算尊重显式值否则取基于 tier 的默认值并被缓存而不是硬编码。该逻辑位于 Hub 生产者 session-shape.ts。文档还保留了一条刻意留存的 parity 差异供评审Hub 对这两个字段采用聚焦解析lenient focused parse而旧路径getSessionUser跑完整的userSettingsSchema.safeParse——后者在 settings blob 里任何无关字段类型错误时整体失败并全部回落默认值。因此对于settings 里有无关坏字段且显式设置了allowAds/redBrowsingLevel的用户Hub 会尊重显式值而旧路径给默认值。要逐位对齐需让getSessionUser也采用聚焦读法——这是一个与收入相邻的变更显式设置allowAdsfalse的用户才真正看不到广告文档作者选择留给显式审批而不单方面改变主应用行为。这条注释展示了迁移中形状对齐与行为对齐是两个不同层次的问题。客户端侧形状src/pages/api/auth/session.ts 是第一方SessionProvider/useSession以及全部约 317 个useCurrentUser调用点轮询的端点返回{ user, expires }形状无会话时返回200 空对象{}而非 401——遵循 next-auth 的既有约定客户端无需感知后端已换代薄会话不向客户端暴露真实的expires端点合成一个 30 天后的时间戳——真正的生命周期由 Cookie maxAge Hub 的吊销标记掌控。SSR 初始会话经由/api/user/settings走同一服务端解析自动保持一致。6. 会话生命周期活动驱动的滚动续期文档 C 节next-auth 时代 JWT 会在活动时被滚动updateAge约 24h活跃用户永不过期。薄civ-token是登录起算的固定窗口因此需要复刻滚动语义Hub 侧POST /api/auth/refreshapps/auth/src/routes/api/auth/refresh/server.ts先验证提交上来的civ-token仍然有效签名 过期 吊销然后为同一用户、同一jti签发一枚新令牌新的 signedAt/exp——延长窗口但不改变会话身份过期/被吊销的令牌直接拒绝→ 重新登录。只有 Hub 能签发主应用是 verify-only。主应用侧maybeRollHubCookiesrc/server/auth/session-client.ts#L70-L89 在每次服务端会话解析成功后执行解码令牌iat若年龄超过AUTH_SESSION_UPDATE_AGE默认24h文档建议后续上调至约 7 天经包内sessionTokenClient.refresh(token, { deviceCookie })带 2.5s 超时向 Hub 换新令牌并通过setSessionCookie在响应上同时重置civ-token与设备 Cookie两者都是最近活动起 30 滚动天。该实现有两条工程约束值得注意源码注释原文提炼best-effort fire-safe任何失败都保留当前仍有效的令牌用户保持登录下次请求重试每次 updateAge 跨越最多触发一次重置 Cookie 即重置了时钟且刷新保持jti不变区别于第 9 节的升级路径——升级会铸造新jti所以需要额外的去重锁。无需任何客户端接线——主应用本就可以设置.civitai.com域 Cookie。7. 设备级多账号切换文档 E 节这是整个 cutover 中最复杂的一块。设计要点设备级device-level而非客户端凭证或 DB 级账号关联——Hub 为每个浏览器维护一个设备集合httpOnlyciv-deviceCookie → Redis hashdevice:accounts:{deviceId}内容为userId → lastSwitchedAt30 天滚动与会话一致登录 切换 滚动续期都会刷新。一次切换的授权 当前活跃会话 目标账号在本设备集合内且新鲜30 天。localStorage里零凭证仅展示用。Hub 侧实现device.ts设备 Cookie Redis 集合link/list/isFresh/remove 30 天剪枝、POST /api/auth/switchapps/auth/src/routes/api/auth/switch/server.ts、GET /api/auth/accountsapps/auth/src/routes/api/auth/accounts/server.ts登录时establishSession → touchAccount自动关联账号。主应用侧同源代理因为.red等站点跨站部署、无法直接用包内浏览器客户端/api/auth/accounts代理GET 列表 DELETE ?userId移除、/api/auth/switch代理转发 → 设置 civ-token → 滚动设备 Cookie以及AccountProvider重写从 Hub 设备集合取列表、swapAccount切换、只登出单个账号而不切换、removeAccount。遗留数据保护切换器把 Hub 设备集合与既有的civitai-accountslocalStorage合并用户在切换过程中不丢任何已关联账号切换到仅存在于 legacy 的条目时在 Hub 侧兑换其存储的令牌同时把该账号关联进设备集合迁移完成后条目从 localStorage 剪除新关联永不写 localStorage。文档列出的剩余项logoutAll登出本设备全部账号需要 Hub 提供忘记本设备账号集合调用——清除 Redis 集合 吊销本设备关联会话且不得影响同用户其他设备与**在所有设备登出**账户页动作走注册表的按用户截止invalidateUserSessions与设备级logoutAll语义完全不同。跨域交换历史实现现已移除文档详细记录了基于顶层导航的SameSiteLax安全流程带凭证的 fetch 无法跨站携带 Hub Cookiespoke/api/auth/sync→ 顶层重定向到 Hub/api/auth/sync?callback…returnUrl…→ Hub 读自己的 Lax Cookie、铸造一次性swap 令牌 → 回跳 spoke → spoke 服务端到服务端POST /api/auth/exchange兑换swap 令牌本身即凭证→ 设置本域 Cookie。一次性由verifySwapToken暴露的jti HubsetNX烧录swap:used:{jti} TTL保证被从重定向 URL 截获的令牌无法重放。该桥现已删除跨域登录改走 OAuth 授权码 PKCE 第一方桥——对照当前 spoke-integration-guide.md。架构规则适用于所有 spoke→Hub 调用不允许手搓 Hub 调用。所有请求必须经过civitai/auth助手应用代码永远不内联 Hub URL/契约。当时的助手面createSessionClient令牌→用户 服务级 invalidate/refresh、createDeviceAccountClient列表/切换/移除设备 Cookie 透传、createSessionTokenClient滚动刷新 吊销令牌鉴权。应用代理只做框架胶水如设置 Next 响应 Cookie。8. 审核员模拟登录文档 F 节与账号切换刻意分离授权模型不同所有权 vs 审核员特权。唯一授权门槛是请求者本人是审核员——没有内部令牌、没有额外凭证、不查所有权/设备也不得触碰设备账号集合目标不是被关联账号。HubPOST /api/auth/impersonate请求者自身会话必须是审核员唯一闸门→ 为目标铸造带impersonatedBy: modIdclaim 的薄civ-token→ 写ModActivity审计行。Hub 侧路由已就位apps/auth/src/routes/api/auth/impersonate/server.ts 与 exit/server.ts。退出模拟不再依赖localStorage的ogAccount——而是读取impersonatedByclaim 重新铸造审核员会话。这一点在当前主应用代码中已落地getHubSession 在 L50 解码impersonatedBy——claim 是身份性的identity-only不含凭证仅用于让客户端显示退出模拟控件。文档保留的验收项impersonate → 以用户身份操作 → 退出回到审核员的 e2e 验证以及主应用impersonate.ts路由到 Hub保留禁止自我模拟的守卫。9. 遗留 Cookie 迁移从可选静默升级到读时升级文档 G 节 当前实现文档 G 节把静默升级列为可选但推荐请求带有有效 legacycivitai-token但没有civ-token时透明地在 Hub 侧铸造civ-token不经过登录界面让用户免重新登录完成迁移不做的话遗留 Cookie 也只是自然老化退出。当前源码显示该升级已实现为upgrade-on-read并针对一个真实的滥用向量做了加固maybeUpgradeLegacySessionsrc/server/auth/session-client.ts#L91-L173每枚遗留 Cookie 每窗口只升级一次而非每请求一次升级会铸造新jti若按请求触发一个不持久化Set-Cookie的客户端脚本化集成、无 Cookie 的 HTTP 客户端会无限重复铸造既无年龄门控也无限流。实现用SHA-256 指纹只存哈希不存原值指纹不是凭证作为 keysysRedis.set(key, 1, { NX: true, EX: 600 })做 10 分钟去重窗口。fail-openredis 抖动不阻断迁移退化为旧的每请求升级行为不算回归。升级流程sessionTokenClient.exchangeLegacy(legacyToken, { deviceCookie })透传已有civ-device让 Hub 复用本浏览器设备集合纯 legacy 用户则由 Hub 铸造设备 Cookie 返回——否则升级后的会话不会出现在账号切换器里→ 拿到新civ-token→setSessionCookie同步设置 civ-token 设备 Cookie → 在同一响应里clearLegacyCookies清空所有遗留 next-auth Cookie会话 CSRF/callback-url/state/PKCE 等杂项。全程 best-effortHub 抖动时遗留 Cookie 原样保留本请求已由遗留解码服务下一次请求重试。升级成功打legacy-session-upgraded日志含解析后的userId。指标侧observeLegacyDecode()独立计数遗留解码仍在发生为最终删除遗留解码路径提供依据。10. 五阶段拆除计划与STEP-H-REMOVAL追踪文档 H 节文档的核心决策是在上线前彻底移除 NextAuth而不是保留翻回 NextAuth的开关混合态。理由是翻回安全网是虚假的——用户一旦在 Hub 登录就持有civ-token把开关翻回 NextAuth 会无视该 Cookie→ 登出用户而如果 Hub 恰是故障源用户连重新登录的机会都没有。混合态的安全网每天都在缩水牺牲的却是最要紧的会话。替代方案是主应用独立于 Hub 验证会话本地验签 共享缓存因此存量会话能扛住 Hub 故障受影响的只有新登录Hub 无论如何都是登录权威用 Hub 高可用缓解。五阶段滚动每阶段保持应用可用NextAuth 活到最后一刻阶段内容1. 韧性解析本地验签 缓存 → Hub 解析链2. 遗留解码器jose解码civitai-tokengetServerAuthSession解析新/旧令牌无 NextAuth3. 账号切换 模拟登录 Hub 原生化E F见第 7、8 节4. 客户端用第一方 Provider 替换next-auth/reactSessionProvider/useSession走/api/auth/session约 317 个useCurrentUser调用点透明切换signIn/signOut本就已路由到 Hub5. 删除服务端 NextAuth[...nextauth].ts、next-auth-options、token-refresh、AES civ-token删除依赖可执行的拆除追踪机制每一个新增或依赖的 NextAuth 触点都携带STEP-H-REMOVAL:代码注释。到 Step H 时grep -rn STEP-H-REMOVAL src packages即得穷尽的移除清单目标是执行后next-auth引用归零。文档中的盘点表摘选关键行位置是什么Step-H 动作src/pages/api/auth/[...nextauth].tsNextAuth 捕获全部处理器 signIn/signOut 事件删除src/server/auth/next-auth-options.tscreateAuthOptions、jwt()/session()回调、providers、adapter、AES 账号切换、legacy JWE 编解码删除E/F 迁移到 Hub 后src/server/auth/get-server-auth-session.tslegacygetServerSession块 Session类型导入删块Session类型用第一方类型替换它是全应用的返回类型src/utils/auth-helpers.tshandleSignIn/handleSignOut中的 next-auth 兜底删兜底 导入Hub 路径保留src/components/UpdateRequiredWatcher/UpdateRequiredWatcher.tsxSESSION_REFRESH_HEADER分支调 next-authupdate()其服务端 setter 已删分支已死删该分支由信号机制session-invalidation.ts取代保留 generation-update 分支src/shared/constants/auth.constants.ts与civitai/auth重复的SESSION_REFRESH_HEADER/COOKIE 非鉴权的GENERATION_UPDATE_HEADER迁出后者删除文件src/pages/api/auth/civ-token.ts死掉的 AES civ-token 端点无调用方删除可提前于 Phase 5next-authnext-auth/react依赖全应用导入含约 317 个客户端调用点✅已完成——根应用与civitai/auth均无 next-auth 导入残留端点处置清单src/pages/api/auth/*逐文件审计——迁移只删两个其余都保留且各有理由删除civ-token.ts死端点无调用方、[...nextauth].tsPhase 5legacy 兑换 Hub 原生化后删。保留oauth/*jwks.tsOIDC 提供方Sign in with Civitaijwks.ts即其jwks_uriaccounts.ts/switch.ts/impersonate.ts主应用到 Hub 的同源代理post-login.ts在 civitai.com 上执行 Hub 够不着的登录副作用——ref_*Cookie、Tracker、referral、社区加入通知抽取为 login-side-effects.ts 的runLoginSideEffects新旧两条登录路径共用新用户/老用户由user.createdAt判定logout.ts清 civ-token 遗留civitai-token orchestrator Cookie并在 Hub 侧吊销session.ts成为第一方{ user, expires }端点freshdesk.ts独立功能user-from-token.ts集成令牌 webhook 工具仓库内无调用方但外部集成可能依赖需确认后再删。注意原清单中的sync.ts跨域登录的 swap 令牌接收端已随 swap 桥整体移除。环境/运维清单每环境AUTH_JWKS_URI、AUTH_JWT_ISSUER已设共享 redis 已确认Hub 持有 EC P-256 密钥对AUTH_JWT_PRIVATE_KEY/AUTH_JWT_PUBLIC_KEY/AUTH_JWT_KIDJWKS 对每个 spoke含 civitai.red可达。11. 切换验证流程与测试策略文档给出的如何翻开关 验证历史操作当时开关存在确认前置条件该环境的 Hub 在生产 是登录权威 环境变量就绪客户端/api/auth/session已实现——服务端与客户端约定一致设置USE_HUB_SESSIONtrue验证Hub 登录 → tRPC/API 调用中getServerAuthSession返回用户 → 客户端useCurrentUser可解析 → refresh/封禁失效传播正常。撤销开关即可瞬时回滚。测试策略的结论是分层防御getHubSession是civitai/authcreateSessionClient的薄包装解析/验签/缓存/拉取逻辑由包的 58 个单元测试覆盖见 packages/civitai-auth/src/tests/含session-client.test.ts、verify.test.ts、legacy-cookie.test.ts等主应用当时没有单元测试运行器仅 Playwright e2e因此主应用端到端路径的最佳验证方式是对一个真实生产中的 Hub 跑 e2e或者给主应用也加 vitestapps/auth已是这么做的。文档 B 节还记录了浏览器冒烟的具体走法未登录访问/generate→/login→ Hub 邮箱登录 →civ-token落定 →/api/auth/post-login副作用 → 重定向回/generate。12. 对照当前仓库文档与代码的现状核对把文档的最终声明与当前源码交叉验证可以得到一张干净的落地清单已拆除文档声明代码印证USE_HUB_SESSION开关在src/与apps/中已无任何引用src/pages/api/auth/下[...nextauth].ts、sync.ts、civ-token.ts均不存在/api/auth/session.ts已是纯第一方端点session.ts 第 4–6 行注释明确写着取代了旧 next-auth[...nextauth]的 session 路由legacyaccount-switch-hub接收端STEP-H 清理项已删。保留并长期存在jose 遗留解码器只读随旧 Cookie 老化退出、upgrade-on-read 升级路径、滚动续期maybeRollHubCookie、Session类型的第一方化get-server-auth-session.ts 顶部注释仍标记着FINAL-CLEANUPSession类型替换是next-auth依赖彻底移除的收尾项。当前跨域模型以 spoke-integration-guide.md 为准OAuth 授权码 PKCE 第一方桥swap-token 桥相关内容仅具历史价值。这份文档的价值在于它把一次大型安全关键路径替换的完整决策链留了下来为什么灰度、灰度何时失效虚假安全网论证、五阶段如何各自保持应用可用、用 grep-able 注释保证拆除穷尽性、以及每个保留/删除端点的逐条理由——这套方法论比迁移本身更值得同类改造任何从内建鉴权框架迁移到自建认证中心的项目直接借鉴。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考