AngularFire 路由守卫实战：用 AngularFireAuthGuard 保护 Angular 路由（Compat API）

后端【免费下载链接】angularfireAngular Firebase ❤️项目地址https://gitcode.com/gh_mirrors/an/angularfire点击查看免费下载AngularFireAuthGuard是 AngularFire 内置的基于AngularFireAuth的canActivate路由守卫 为主体结合 auth-guard 源码 与 测试用例系统讲解从开箱即用、预置管道、自定义管道到基于路由状态动态授权的完整方案。注意AngularFire 已提供新的 tree-shakable API本文描述的是库的compat兼容版本文档。关于这一变化的更多信息请参阅 v7 升级指南。快速开始默认拒绝未认证用户在 compat 版本中AngularFireAuthGuard从angular/fire/compat/auth-guard导入。将其直接放入路由的canActivate数组即可生效——默认行为是未登录的用户不允许导航到受保护路由。import { AngularFireAuthGuard } from angular/fire/compat/auth-guard; export const routes: Routes [ { path: , component: AppComponent }, { path: items, component: ItemListComponent, canActivate: [AngularFireAuthGuard] }, ]从源码看默认行为确实如此auth-guard.ts 中canActivate会先从next.data.authGuardPipe读取自定义管道取不到时回退到默认的loggedIn管道而loggedIn的定义只是一行map(user !!user)auth-guard.ts即“用户存在即放行”。使用前需要把AngularFireAuthGuardModule引入模块。模块本身只做了两件事在 providers 中注册守卫以及调用firebase.registerVersion(angularfire, VERSION.full, auth-guard-compat)上报版本信息auth-guard.module.ts。参考测试中的配置方式auth-guard.spec.ts典型模块配置如下import { AngularFireModule } from angular/fire/compat; import { AngularFireAuthGuardModule } from angular/fire/compat/auth-guard; import { RouterModule } from angular/router; NgModule({ imports: [ AngularFireModule.initializeApp(environment.firebase), AngularFireAuthGuardModule, RouterModule.forRoot(routes), ], }) export class AppModule { }定制守卫行为authGuardPipe要定制AngularFireAuthGuard的行为可以通过路由数据route data的authGuardPipe键传入一个RxJS 管道pipe。守卫拿到的是当前用户的可观察对象ObservableUser | null管道把它转换成布尔值放行/拒绝或数组重定向目标。angular/fire/compat/auth-guard模块提供了以下预置管道| 导出的管道 | 功能 | |-|-| |loggedIn| 默认管道用户未认证时拒绝。 | |isNotAnonymous| 用户为匿名登录时拒绝。 | |emailVerified| 用户邮箱未验证时拒绝。 | |hasCustomClaim(claim)| 用户不具备指定自定义声明claim时拒绝。 | |redirectUnauthorizedTo(redirect)| 将未认证用户重定向到其他路由。 | |redirectLoggedInTo(redirect)| 将已认证用户重定向到其他路由。 |这些预置管道的实现同样集中在 auth-guard.tsisNotAnonymousmap(user !!user !user.isAnonymous)emailVerifiedmap(user !!user user.emailVerified)customClaims通过getIdTokenResult()取出 ID Token 中的 claimshasCustomClaim(claim)基于customClaims用hasOwnProperty(claim)判断是否存在该声明redirectUnauthorizedTo(redirect)loggedIn || redirect未登录时产出重定向目标数组redirectLoggedInTo(redirect)loggedIn redirect || true已登录时重定向否则放行返回true。完整示例登录页、后台页与账号级权限下面这个示例同时用到了自定义声明校验与两个重定向管道覆盖了最常见的三种场景import { AngularFireAuthGuard, hasCustomClaim, redirectUnauthorizedTo, redirectLoggedInTo } from angular/fire/compat/auth-guard; const adminOnly () hasCustomClaim(admin); const redirectUnauthorizedToLogin () redirectUnauthorizedTo([login]); const redirectLoggedInToItems () redirectLoggedInTo([items]); const belongsToAccount (next) hasCustomClaim(account-${next.params.id}); export const routes: Routes [ { path: , component: AppComponent }, { path: login, component: LoginComponent, canActivate: [AngularFireAuthGuard], data: { authGuardPipe: redirectLoggedInToItems }}, { path: items, component: ItemListComponent, canActivate: [AngularFireAuthGuard], data: { authGuardPipe: redirectUnauthorizedToLogin }}, { path: admin, component: AdminComponent, canActivate: [AngularFireAuthGuard], data: { authGuardPipe: adminOnly }}, { path: accounts/:id, component: AdminComponent, canActivate: [AngularFireAuthGuard], data: { authGuardPipe: belongsToAccount }} ];注意这里的模式adminOnly、belongsToAccount等都以函数形式出现返回管道而redirectUnauthorizedToLogin和redirectLoggedInToItems则把重定向目标作为参数传入预置管道。这是因为authGuardPipe的类型实际上既可以是管道本身也可以是“给定路由快照、返回管道”的生成器函数见下文“使用路由状态”一节。用canActivate辅助函数让路由更简洁每次都写canActivate: [...]加data: { authGuardPipe: ... }略显啰嗦。angular/fire/compat/auth-guard还导出了一个canActivate辅助函数配合展开语法spread syntax可以让路由配置更易读import { canActivate } from angular/fire/compat/auth-guard; export const routes: Routes [ { path: , component: AppComponent }, { path: login, component: LoginComponent, ...canActivate(redirectLoggedInToItems) }, { path: items, component: ItemListComponent, ...canActivate(redirectUnauthorizedToLogin) }, { path: admin, component: AdminComponent, ...canActivate(adminOnly) }, { path: accounts/:id, component: AdminComponent, ...canActivate(belongsToAccount) } ];从源码看canActivate只是一个把“管道生成器”包装成标准路由配置片段的语法糖auth-guard.tsexport const canActivate (pipe: AuthPipeGenerator) ({ canActivate: [ AngularFireAuthGuard ], data: { authGuardPipe: pipe } });它返回的对象包含canActivate: [AngularFireAuthGuard]和data: { authGuardPipe: pipe }展开到路由对象里正好等价于前面手写的形式。使用这种写法时传入的pipe参数建议同样用函数包装如() redirectUnauthorizedTo([login])以保证每次导航都生成独立的管道实例。组合你自己的管道AngularFireAuthGuard的管道本质上是RxJS 操作符它们把可选的User转换成布尔值放行/拒绝或数组重定向目标。因此你可以非常自然地用 RxJS 操作符组合出任意规则。示例一按用户状态分流下面的自定义管道把用户重定向到其“个人资料编辑页”若未登录则重定向到“登录页”import { map } from rxjs/operators; // This pipe redirects a user to their profile edit page or the login page if theyre unauthenticated // { path: profile, ...canActivate(redirectToProfileEditOrLogin) } const redirectToProfileEditOrLogin () map(user user ? [profiles, user.uid, edit] : [login]);当用户存在时管道产出[profiles, user.uid, edit]这样的重定向数组uid是 Firebase 用户的唯一标识用户不存在时产出[login]。示例二用customClaims简化声明检查auth-guard模块还提供了一个customClaims操作符用于减少检查用户自定义声明时的样板代码。它内部通过user.getIdTokenResult()拿到 ID Token 并提取claims未登录时产出空数组[]见 auth-guard.tsimport { pipe } from rxjs; import { map } from rxjs/operators; import { customClaims } from angular/fire/compat/auth-guard; // This pipe will only allow users with the editor role to access the route // { path: articles/:id/edit, component: ArticleEditComponent, ...canActivate(editorOnly) } const editorOnly () pipe(customClaims, map(claims claims.role editor));这里claims就是 ID Token 解码后的 payload 对象claims.role editor直接返回布尔值决定是否放行。相比每次手写getIdTokenResult().then(...)再转 Observable这种声明式写法清晰得多。hasCustomClaim预置管道正是基于同一机制实现的。使用路由状态AuthPipeGenerator有时授权规则依赖于当前路由的参数。AngularFireAuthGuard接受AuthPipeGenerator——即“给定路由快照生成管道”的函数。其类型定义auth-guard.ts为export type AuthPipeGenerator (next: ActivatedRouteSnapshot, state: RouterStateSnapshot) AuthPipe; export type AuthPipe UnaryFunctionObservablefirebase.User|null, Observableboolean|string|any[];这意味着你的自定义函数可以接收next即将激活的路由快照含params、data等信息来动态决定授权逻辑import { pipe } from rxjs; import { map } from rxjs/operators; import { customClaims } from angular/fire/compat/auth-guard; // Only allow navigation to the route if :userId matches the authenticated users uid // { path: user/:userId/edit, component: ProfileEditComponent, ...canActivate(onlyAllowSelf) } const onlyAllowSelf (next) map(user !!user next.params.userId user.uid); // Only allow navigation to the route if the user has a custom claim matching :accountId // { path: accounts/:accountId/billing, component: BillingDetailsComponent, ...canActivate(accountAdmin) } const accountAdmin (next) pipe(customClaims, map(claims claims[account-${next.params.accountId}-role] admin));onlyAllowSelf要求当前登录用户的uid与路由参数userId一致防止用户编辑他人的资料accountAdmin要求用户的 ID Token 中包含account-accountId-role声明且值为admin实现按账号维度的租户级/组织级权限控制。这种“根据next.params动态生成管道”的能力正是belongsToAccount、redirectUnauthorizedTo等预置管道能接受参数的原因——守卫在每次导航时都会调用authPipeFactory(next, state)重新生成管道。源码级原理守卫内部发生了什么理解AngularFireAuthGuard的执行流程有助于排查授权问题。核心实现在 auth-guard.tscanActivate (next: ActivatedRouteSnapshot, state: RouterStateSnapshot) { const authPipeFactory next.data.authGuardPipe as AuthPipeGenerator || (() loggedIn); return this.auth.user.pipe( take(1), authPipeFactory(next, state), map(can { if (typeof can boolean) { return can; } else if (Array.isArray(can)) { return this.router.createUrlTree(can); } else { return this.router.parseUrl(can); } }) ); }整个流程分四步读取管道优先取路由数据中的authGuardPipe缺省回退到loggedIn取一次用户this.auth.user.pipe(take(1))——只取当前认证状态的一次快照不做持续订阅。AngularFireAuth.user是“当前登录用户或 null”的 Observable见 AngularFireAuth 源码由onIdTokenChanged驱动执行管道把用户流交给你的AuthPipe/AuthPipeGenerator处理解释结果产出布尔值true放行、false拒绝导航产出数组如[login]、[profiles, uid, edit]时调用this.router.createUrlTree(can)创建 URL 树完成重定向产出字符串时AuthPipe类型也允许string调用this.router.parseUrl(can)解析为 URL 完成重定向该分支在源码中标注了待补测试的 TODO。此外compat 版本的AngularFireAuth是懒加载的 promise 代理实现auth.ts守卫的user流经由shareReplay缓存多个守卫并发执行时也会复用同一份认证状态不会重复触发 SDK 初始化。测试与验证仓库为守卫提供了基础可注入性测试auth-guard.spec.ts 中配置了包含AngularFireModule.initializeApp(COMMON_CONFIG, rando())、AngularFireAuthGuardModule与RouterModule.forRoot([{ path: a, component: TestComponent, canActivate: [AngularFireAuthGuard] }])的测试模块并断言router可正常注入。这为我们验证路由配置是否正确提供了一个可复用的最小骨架注册模块、配置路由、注入Router即可驱动守卫逻辑。如果希望使用新的 tree-shakable API 而非 compat 版本可参考 新式 AuthGuard 源码——其 API 形态与本文完全平行AuthGuard、canActivate、loggedIn、customClaims等只是底层从AngularFireAuthcompat换成了Authuser(this.auth)modular。实战注意事项take(1)语义守卫只读取一次认证状态因此不要在守卫管道里依赖“等待异步登录完成”这类时序若需要先确保用户完成登录再进入路由应配合登录流程在导航前完成。重定向目标是数组还是字符串预置管道与官方示例均使用数组如[login]这会经过createUrlTree生成相对 URL传入字符串路径同样受支持但会走parseUrl分支。redirectLoggedInTo的“反向”语义它面向登录页等场景——已登录用户访问登录页时被弹回如[items]未登录用户则放行进入登录页。自定义声明时效customClaims基于 ID Token 中的 claimsToken 刷新前对用户属性的修改不会立刻反映到守卫结果中。路由复用使用AuthPipeGenerator时请始终以函数形式返回新管道() ...避免多个路由共享同一管道实例导致参数残留。至此你已经掌握了从默认拦截、预置管道、自定义 RxJS 管道到基于路由参数动态授权AuthPipeGenerator的完整路由守卫方案并了解了其底层实现与验证方式。赞分享后端【免费下载链接】angularfireAngular Firebase ❤️项目地址https://gitcode.com/gh_mirrors/an/angularfire点击查看免费下载相关推荐Nebular Auth 路由守卫实战基于用户认证状态保护 Angular 路由Nebular Auth 路由守卫实战基于用户认证状态保护 Angular 路由 导读 本文以 Nebular Auth 模块为背景讲解如何利用 Angul前端UI组件Angular路由参数订阅awesome-angular路由守卫Angular路由参数订阅awesome angular路由守卫 你是否在Angular应用中遇到过这样的问题用户在详情页切换ID时组件没有重新加载数据文档MakerDAO测试网部署指南添加自定义抵押类型的完整步骤MakerDAO测试网部署指南添加自定义抵押类型的完整步骤 MakerDAO测试网部署指南是开发者集成MakerDAO智能合约、SDK和API的关键步骤本教上一篇Xenia Canary模拟器性能调优与配置深度指南5个核心问题解决方案下一篇Komodo缓存策略提升频繁访问数据的响应速度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考