理解 Angular 路由守卫 (Route Guards)
Angular 路由守卫是实现导航权限控制的核心机制。它们允许我们在用户尝试访问某个路由之前、离开某个路由之前或懒加载模块之前执行逻辑。其中，CanActivate 守卫用于决定是否允许用户进入某个路由。当一个路由配置了 canActivate 守卫时，只有当守卫返回 true 时，路由才会被激活；如果返回 false 或 UrlTree，则导航会被取消或重定向。
在 Monorepo 架构中，当父应用负责定义所有子应用的懒加载路由时，一个常见的需求是，子应用本身应该能够控制谁可以访问它，而不是让父应用硬编码这些权限逻辑。
Monorepo 中模块化访问控制的挑战与解决方案
传统上，canActivate 守卫直接在父应用的路由配置中引用。如果守卫的实现包含了特定于某个子应用的权限逻辑，那么这似乎违背了“逻辑不放在父应用”的原则。然而，关键在于守卫的 定义位置 和 实现细节。
解决方案的核心思路是：将针对特定子应用的权限守卫定义在 该子应用自身 的代码库中（或一个共享库中），然后由父应用在路由配置中引用这个守卫。这样，虽然父应用仍然配置了守卫，但守卫的 具体逻辑 却由子应用（或其模块化部分）提供，从而实现了逻辑的解耦。
1. 创建子应用专属的访问守卫
首先，在你的子应用（例如 project1）的代码库中创建一个路由守卫。为了更好地组织，如果 project1 是一个 Angular Library，可以将其放在 src/lib 目录下。
projects/project1/src/lib/project1.guard.ts
import { Injectable } from '@angular/core';
import { CanActivate, ActivatedRouteSnapshot, RouterStateSnapshot, UrlTree, Router } from '@angular/router';
import { Observable } from 'rxjs';
import { AuthService } from '@app/shared/services/auth.service'; // 假设存在一个共享的认证服务
@Injectable({
providedIn: 'root' // 或者在 Project1Module 中提供
})
export class Project1Guard implements CanActivate {
constructor(private authService: AuthService, private router: Router) {}
canActivate(
route: ActivatedRouteSnapshot,
state: RouterStateSnapshot): Observable | Promise | boolean | UrlTree {
// 这里是 Project1 特有的访问控制逻辑。
// 这段逻辑属于 Project1 模块的职责范围。
const hasAccess = this.authService.checkPermissionForModule('project1'); // 调用共享服务检查 Project1 权限
if (hasAccess) {
console.log('用户拥有 Project1 的访问权限。');
return true; // 允许访问
} else {
console.warn('用户没有 Project1 的访问权限。重定向到未授权页面...');
// 如果没有权限，可以重定向到登录页或未授权页面
return this.router.createUrlTree(['/unauthorized']);
}
}
} 在上述代码中，Project1Guard 负责判断用户是否有权访问 project1。它依赖一个共享的 AuthService 来获取用户的权限信息。AuthService 可以是一个全局服务，它知道如何查询用户的角色或权限列表。checkPermissionForModule('project1') 方法是关键，它封装了判断用户对 project1 模块是否有权限的逻辑。
2. 共享认证服务示例
为了使 Project1Guard 能够检查权限，我们需要一个能够提供用户认证和授权信息的服务。这个服务通常是共享的，可以放在 Monorepo 的一个共享库中，或者直接在父应用中定义并提供。
apps/parent-app/src/app/shared/services/auth.service.ts (示例)
import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable } from 'rxjs';
@Injectable({
providedIn: 'root'
})
export class AuthService {
private isAuthenticatedSubject = new BehaviorSubject(false);
isAuthenticated$: Observable = this.isAuthenticatedSubject.asObservable();
// 假设的用户权限列表
private userPermissions: string[] = ['dashboard', 'project1']; // 模拟用户拥有 'project1' 权限
constructor() {
// 模拟用户已登录
this.isAuthenticatedSubject.next(true);
}
login(username: string, password: string): void {
// 实际的登录逻辑，可能调用后端API
console.log(`用户 ${username} 尝试登录...`);
this.isAuthenticatedSubject.next(true);
// 模拟获取用户权限
this.userPermissions = ['dashboard', 'project1']; // 登录成功后更新权限
}
logout(): void {
this.isAuthenticatedSubject.next(false);
this.userPermissions = [];
}
/**
* 检查当前用户是否对特定模块有访问权限。
* 这里的逻辑可以根据实际的权限模型（如基于角色的访问控制 RBAC）进行扩展。
* @param moduleName 要检查的模块名称。
* @returns 如果用户有权限则返回 true，否则返回 false。
*/
checkPermissionForModule(moduleName: string): boolean {
if (!this.isAuthenticatedSubject.getValue()) {
return false; // 未登录用户无权限
}
// 简单检查用户权限列表中是否包含该模块
return this.userPermissions.includes(moduleName);
}
} 3. 在父应用路由中集成守卫
最后，在父应用的路由配置中，引入并使用 Project1Guard。
apps/parent-app/src/app/app-routing.module.ts
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { HomeComponent } from './home/home.component'; // 示例组件
import { UnauthorizedComponent } from './unauthorized/unauthorized.component'; // 示例未授权组件
// 从 project1 库中导入 Project1Guard
// 假设 'project1' 是一个 Angular library 的别名，或者使用相对路径
import { Project1Guard } from '@project1/project1'; // 或 '../../projects/project1/src/lib/project1.guard'
const routes: Routes = [
{ path: '', redirectTo: '/home', pathMatch: 'full' },
{ path: 'home', component: HomeComponent },
{
path: 'project1',
loadChildren: () => import('@project1/project1').then(m => m.Project1Module), // 懒加载 Project1Module
canActivate: [Project1Guard] // 在此处引用 Project1Guard
},
{ path: 'unauthorized', component: UnauthorizedComponent }, // 未授权页面
// ... 其他路由
];
@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule]
})
export class AppRoutingModule { }在这个配置中，父应用只负责声明在访问 /project1 路径时需要激活 Project1Guard。父应用本身并不知道 Project1Guard 内部的权限判断逻辑，它只是依赖于 project1 模块提供这个守卫。这样，project1 模块的权限逻辑就有效地“告诉”了父应用它自己的访问规则，符合了“逻辑不放在父应用”的核心要求。
注意事项与最佳实践
- 守卫的提供方式 (providedIn): 在 Project1Guard 中使用 providedIn: 'root' 是一个常见的做法，它使得守卫可以在整个应用中被注入。如果 project1 是一个独立的 Angular Library，并且你希望这个守卫只在 project1 模块内部使用，或者只在父应用加载 project1 时才被考虑，也可以将其 providedIn 设置为 Project1Module，并确保 Project1Module 被正确导入。然而，对于 canActivate 守卫，通常 providedIn: 'root' 更简洁。
- 错误处理与用户体验: 当 canActivate 返回 UrlTree 进行重定向时，确保重定向的目标路由（如 /unauthorized）能够提供友好的用户提示。
- 共享服务与依赖注入: AuthService 作为共享服务，其设计应尽可能通用，不包含任何特定于某个子应用的逻辑。所有具体的权限判断都应通过传入模块名称或其他标识符来完成，或者由守卫本身结合模块上下文来判断。
- Monorepo 库的别名: 为了保持导入路径的整洁，建议为 Monorepo 中的 Angular Library 配置路径别名（例如 @project1/project1），这在 tsconfig.json 中配置。
- 动态权限配置: 对于更复杂的场景，权限信息可能来自后端，并且可以动态更新。AuthService 应该能够处理这些动态权限数据，并在必要时刷新。
- 多守卫组合: 如果一个路由需要多个权限检查，你可以在 canActivate 数组中配置多个守卫，它们会按顺序执行，任何一个返回 false 或 UrlTree 都会中断导航。
通过以上方法，我们可以在 Angular Monorepo 中实现一种模块化、解耦的用户访问控制方案，使得每个子应用能够有效地管理自身的访问权限，同时保持父应用路由配置的简洁和通用性。
