系列5：【深入】微前端中的权限控制——别让你的子应用为所欲为！

rabbit_it

已于 2024-09-15 17:06:22 修改

阅读量591

点赞数 14

分类专栏： qiankun学习文章标签：前端前端框架阿里云

于 2024-09-15 16:42:39 首次发布

本文链接：https://blog.csdn.net/qq_14811655/article/details/142285904

版权

qiankun学习专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1. 为什么需要权限控制？

想象一下，你家的狗突然学会了打开冰箱，它不再问你，而是每次都自己动手拿食物——这就像是没有权限控制的微前端架构，子应用可以随意访问主应用的资源，甚至窃取其他子应用的数据！可怕吧？这就是我们为什么要搞权限控制，尤其在复杂的微前端架构中，权限不仅仅是个管理工具，更是数据和操作安全的守护者。

开门惊喜-狗在冰箱

在传统单体应用中，权限管理相对简单，因为一切都在同一个应用内部完成。但是，微前端架构的出现打破了这种“帝国模式”，主应用和子应用可以分别由不同团队开发，甚至在不同平台独立运行。没有严格的权限控制，这些子应用可能会有过高的权限，甚至误操作关键数据。

2. 权限的分层设计

权限控制的核心之一就是 分层设计。分层设计就像游戏中的副本层级：主应用是“大佬”，子应用们是“小弟”。我们不能让小弟做大佬的事，也不能让大佬干小弟的活儿。举个例子，主应用负责整个系统的用户认证，而子应用只应该负责处理它自己那部分的功能，比如显示不同的页面内容。

微前端中的权限设计可以分为两种模式：

集中式管理：所有权限逻辑都在主应用处理，子应用从主应用接收权限信息。这就像你是大公司老板，你有权访问所有子公司资源，而子公司只能用你给的权限。
分散式管理：主应用和子应用各自处理自己部分的权限逻辑。这里的挑战在于如何确保权限的一致性，避免“东厂”和“西厂”之间权限不对等，导致混乱局面。

3. 微前端中的动态路由与权限验证

在微前端架构中，动态路由与权限验证是息息相关的。就像你家门口有很多路，但不是每个人都能随便进来，路口的守卫会根据你的身份（权限）放行不同的路线。

动态路由可以根据用户的权限来生成不同的导航菜单和页面。例如，管理员可以看到“系统设置”的选项，而普通用户则只能看到“个人信息”。实现这一点的关键在于，主应用通过用户权限动态生成不同的路由配置，再传递给子应用。

代码示例：

// 主应用根据权限生成路由
const routes = [
  {
    path: '/dashboard',
    name: 'Dashboard',
    component: Dashboard
  },
  {
    path: '/settings',
    name: 'Settings',
    component: Settings,
    meta: { requiresAdmin: true } // 只有管理员才能访问
  }
];

// 全局路由守卫，判断权限
router.beforeEach((to, from, next) => {
  const userRole = getUserRole(); // 获取用户角色
  if (to.meta.requiresAdmin && userRole !== 'admin') {
    next('/no-access'); // 没权限，重定向到无权限页面
  } else {
    next();
  }
});

4. 主子应用之间的权限传递

在微前端架构中，主应用和子应用之间的权限传递尤为重要。子应用相当于“小弟”，需要从主应用（“大佬”）那儿获取权限信息。通过 Qiankun 的 props，我们可以轻松地将权限信息从主应用传递给子应用，确保权限的一致性。

让我们来看一下实际操作中的代码示例：

// 主应用在注册子应用时，传递用户权限信息
registerMicroApps([
  {
    name: 'sub-app',
    entry: '//localhost:7100',
    container: '#container',
    activeRule: '/sub-app',
    props: { userRole: 'admin' } // 传递权限信息给子应用
  }
]);

// 子应用中接收并处理权限
const { userRole } = props;
if (userRole === 'admin') {
  // 显示管理员权限的功能
  showAdminFeatures();
}

通过这种方式，子应用可以根据接收到的权限信息来决定要展示哪些功能或页面，避免越权操作。

5. 基于角色的访问控制（RBAC）

RBAC（Role-Based Access Control，基于角色的访问控制）是权限管理中常用的一种模式。它通过将权限与角色挂钩，再将角色赋予用户，从而简化权限管理。你可以把它想象成一场多人桌游，玩家拿到不同的角色卡，才能执行对应的操作。管理员角色能访问所有资源，而普通用户只能干一些基础的活儿。

在微前端架构下，RBAC 仍然是核心权限管理模式。通过角色，我们可以让主应用和子应用协同工作，根据用户的不同角色来划分操作权限。

RBAC 的实现思路：

定义角色：例如 admin, user, guest。
分配权限：根据角色定义权限，比如 admin 角色能访问所有页面，而 guest 只能访问公共页面。
动态验证：根据用户角色动态调整路由和页面展示内容。

代码示例：

const rolesPermissions = {
  admin: ['viewDashboard', 'editSettings', 'manageUsers'],
  user: ['viewDashboard'],
  guest: ['viewHome']
};

// 根据用户角色判断是否有权限
function hasPermission(role, permission) {
  return rolesPermissions[role]?.includes(permission);
}

// 示例：在子应用中根据权限展示不同内容
if (hasPermission(userRole, 'editSettings')) {
  showSettingsPage();
} else {
  showNoAccessMessage();
}

6. 常见问题与解决方案

权限同步延迟：如果用户权限发生变化，但子应用未及时感知到，可能会导致权限不一致的问题。解决方案是通过主应用广播权限变化事件，确保所有子应用能实时更新权限。
权限泄露：当子应用独立管理权限时，可能会存在某些子应用不严格遵守权限规则，导致权限泄露。这时可以在主应用层进行统一的权限检查，确保所有操作都经过主应用的权限验证。