## 一、为什么需要RBAC？

在项目的第一版设计中，我只有两个角色：「管理员」和「普通用户」。上线一周后就发现不够用了：

- 教务员王老师需要**审核**别人上传的资源，但不应有管理员权限
- 年级组长李老师需要在自己负责的板块下**新建文件夹**分类资料
- 某些板块（如学生成绩）只有特定角色才能看到
- 超级管理员需要全局配置能力，但不能随便给

这些需求催生了**四级角色 × 四大板块**的矩阵权限模型。**RBAC 四级权限矩阵的设计和中间件实现，WorkBuddy 帮我理清了角色继承关系，生成的代码框架几乎能直接跑。对一个非专业后端来说，这种「把复杂权限讲明白」的能力太值钱了。**

## 二、角色层级设计

```
          ┌─────────────┐
          │ superadmin  │  等级4 — 全部权限 + 系统设置 + 安全策略
          │ (超级管理员) │
          └──────┬──────┘
                 │ 继承admin全部能力
          ┌──────▼──────┐
          │    admin    │  等级3 — 全部四板块管理 + 用户管理
          │  (管理员)   │
          └──────┬──────┘
                 │ 继承staff全部能力
          ┌──────▼──────┐
          │    staff    │  等级2 — 全部可见 + 上传/审核/建文件夹
          │  (教务员)   │
          └──────┬──────┘
                 │ 基础能力
          ┌──────▼──────┐
          │   teacher   │  等级1 — 只能看/上传自己的内容
          │  (普通教师)  │
          └─────────────┘
```

### 各角色详细权限表

| 能力 | teacher(1) | staff(2) | admin(3) | superadmin(4) |
|------|:-----------:|:--------:|:--------:|:-------------:|
| **教学资料** | 查看+上传 | 查看+上传+审核+建夹 | 同左+删除 | 全部 |
| **学校管理** | ❌不可见 | 查看+上传+审核+建夹 | 同左+删除 | 全部 |
| **学生成绩** | ❌不可见 | 查看+上传+审核+建夹 | 同左+删除 | 全部 |
| **活动照片** | 查看+上传 | 查看+上传+审核+建夹 | 查看+审核 | 全部 |
| 审核他人资源 | ❌ | ✅ | ✅ | ✅ |
| 新建文件夹 | ❌ | ✅ | ✅ | ✅ |
| 用户管理 | ❌ | ❌ | ✅ | ✅ |
| 系统设置 | ❌ | ❌ | ❌ | ✅ |

![screenshot_05_admin_dashboard_clean.png](https://developer.qcloudimg.com/http-save/yehe-12595092/2a19ba867cf596b89d75a179c978c616.png)

![screenshot_11_admin_users_clean.png](https://developer.qcloudimg.com/http-save/yehe-12595092/ec318b99a266c30211e0233fa5db5102.png)

![screenshot_14_admin_settings_clean.png](https://developer.qcloudimg.com/http-save/yehe-12595092/d87d916306a760c8cd106dbe1da4d6ec.png)

## 三、权限矩阵的数据结构

```javascript
// middleware/rbac.js — 权限矩阵定义
const PERM_MATRIX = {
  // 板块slug → { 角色level → 权限字符串 }
  teaching: {
    1: 'rw',     // teacher: 可读(r)+可写(w)
    2: 'rwa',    // staff: 可读+可写+审核(a)
    3: 'rwa',    // admin
    4: 'rwa'     // superadmin
  },
  school_admin: {
    1: '-',      // teacher: 无权限
    2: 'rw',     // staff
    3: 'rwa',
    4: 'rwa'
  },
  student_grade: {
    1: '-',
    2: 'rw',
    3: 'rwa',
    4: 'rwa'
  },
  activity_photo: {
    1: 'rw',
    2: 'rwa',
    3: 'ra',     // admin只能读和审核，不能上传活动照片
    4: 'rwa'
  }
};
```

权限字符含义：
- `r` = read（查看列表和详情）
- `w` = write（上传/编辑/删除自己的内容）
- `a` = approve（审核他人的资源）
- `-` = 无任何权限（前端不显示该板块）

## 四、RBAC中间件实现

### 核心鉴权逻辑

```javascript
// middleware/rbac.js
const db = require('../db');

/**
 * RBAC权限校验中间件工厂
 * @param {string} requiredAction - 要求的最低权限 ('r' | 'w' | 'a')
 * @returns {Function} Express中间件
 */
function rbacMiddleware(requiredAction = 'r') {
  return (req, res, next) => {
    const user = req.user;  // 由auth中间件注入

    // 1. 获取请求的目标板块ID
    const categoryId = req.params.categoryId || req.body?.categoryId;

    if (!categoryId) {
      // 如果没有明确的板块ID（如访问统计页），放行——路由层自行处理
      return next();
    }

    // 2. 根据category_id查对应的slug
    const category = db.prepare(
      'SELECT slug FROM categories WHERE id = ?'
    ).get(categoryId);

    if (!category) {
      return res.status(404).json({ code: 404, message: '分类不存在' });
    }

    // 3. 查权限矩阵
    const matrix = PERM_MATRIX[category.slug];
    if (!matrix) {
      return res.status(500).json({ code: 500, message: '未配置该板块权限' });
    }

    const perm = matrix[user.roleLevel] || '-';

    // 4. 完全无权限
    if (perm === '-') {
      return res.status(403).json({
        code: 403,
        message: `您无权访问"${category.slug}"板块`
      });
    }

    // 5. 需要写入/审核权限但当前角色没有
    if (['a', 'w'].includes(requiredAction) && !perm.includes(requiredAction)) {
      return res.status(403).json({
        code: 403,
        message: '权限不足'
      });
    }

    // 6. 特殊限制：teacher不能新建文件夹、不能审核
    if (user.roleLevel <= 1) {
      if (req.path.includes('/folder')) {
        return res.status(403).json({
          code: 403,
          message: 'teacher角色无新建文件夹权限'
        });
      }
      if (req.path.includes('/review')) {
        return res.status(403).json({
          code: 403,
          message: 'teacher角色无审核权限'
        });
      }
    }

    next();
  };
}

module.exports = rbacMiddleware;
```

### 使用方式

```javascript
// routes/resources.js — 不同操作需要不同权限级别
const auth = require('./middleware/auth');
const rbac = require('./middleware/rbac');

// 浏览资源列表 —— 只需读权限（所有能看到的角色都可以）
router.get('/', auth, rbac('r'), listResources);

// 上传资源 —— 需要写权限
router.post('/upload', auth, upload.single('file'), rbac('w'), uploadResource);

// 审核资源 —— 需要审核权限
router.put('/:id/review', auth, requireReviewRole, reviewResource);

// 删除资源 —— 需要写权限（且只能删自己上传的或admin以上）
router.delete('/:id', auth, rbac('w'), deleteResource);

// 新建文件夹 —— 特殊限制（staff及以上）
router.post('/folder', auth, rbac('w'), createFolder);
```

## 五、前后端双重校验

> 🏗️ 架构原则：**前端隐藏无权UI是用户体验优化，后端API拦截才是真正的安全防线。**

### 前端：条件渲染

```vue

<template>
  <div class="resource-card">
    
    <h3>{{ resource.originalName }}</h3>
    <p>{{ resource.sizeText }}</p>

    
    <div v-if="canEdit" class="actions">
      <button @click="handlePreview">预览</button>
      <button @click="handleDownload">下载</button>
      <button v-if="isOwner || isAdmin" @click="handleDelete">删除</button>
    </div>

    
    <button v-if="canReview && resource.status === 'pending'"
            @click="openReviewDialog">
      审核
    </button>
  </div>
</template>

<script setup lang="ts">
import { computed } from 'vue';
import { useAuth } from '../composables/useAuth';

const props = defineProps<{ resource: any }>();
const { user } = useAuth();

const canEdit = computed(() => {
  // 有写权限的角色都能看到基本操作
  return user.value && user.value.roleLevel >= 1;
});

const isOwner = computed(() => {
  return user.value?.userId === props.resource.uploader_id;
});

const isAdmin = computed(() => {
  return user.value?.roleLevel >= 3;
});

const canReview = computed(() => {
  // 只有staff及以上才能审核
  return user.value && user.value.roleLevel >= 2;
});
</script>
```

### 后端：强制校验（即使前端绕过也不怕）

```javascript
// 删除接口示例：后端必须再次验证
router.delete('/:id', auth, rbac('w'), (req, res) => {
  const resourceId = req.params.id;

  // 查询资源信息
  const resource = db.prepare(
    'SELECT uploader_id FROM resources WHERE id = ?'
  ).get(resourceId);

  if (!resource) {
    return res.status(404).json({ code: 404, message: '资源不存在' });
  }

  // 非管理员只能删除自己的资源
  if (req.user.roleLevel < 3 && req.user.userId !== resource.uploader_id) {
    return res.status(403).json({ code: 403, message: '只能删除自己上传的资源' });
  }

  // 执行删除...
  db.prepare('DELETE FROM resources WHERE id = ?').run(resourceId);
  res.json({ code: 200, message: '已删除' });
});
```

**为什么需要双重校验？** 因为前端的任何逻辑都可以被绕过（浏览器开发者工具→直接发HTTP请求）。后端的权限检查是最后一道防线，永远不能省。

## 六、特殊场景的权限设计

### 场景1：teacher 为什么不能新建文件夹？

最初设计时teacher可以建文件夹。后来发现问题：
- teacherA创建了「期末复习」子文件夹
- teacherB不知道这个文件夹的存在，也在同级建了同名文件夹
- 资源分散在多个重复文件夹里，反而更乱

**决策**：将「新建文件夹」收归staff及以上。teacher只管上传到已有的分类结构中，由教务员统一维护目录树。这增加了教务员的一点工作量，但换来了整体结构的整洁。

### 场景2：activity_photo 板块的admin权限为什么只有`ra`？

大多数情况下，活动照片由老师们上传（运动会、表彰会等现场拍照）。admin的角色定位是「管理和监督」，不应该亲自参与内容生产——所以admin对活动照片板块只有读(r)和审核(a)权限，没有写(w)权限。

这是一个**业务逻辑约束**覆盖通用层级规则的例子——说明权限设计不是纯粹的数学递增关系，必须结合实际使用场景来调整。

### 场景3：审核权的独立控制

审核是一个敏感操作（决定内容是否公开）。我们用了一个独立的中间件`requireReviewRole`：

```javascript
// middleware/rbac.js — 审核角色专用中间件
function requireReviewRole(req, res, next) {
  // 只有roleLevel >= 2 的用户才能执行审核操作
  if (req.user.roleLevel < 2) {
    return res.status(403).json({
      code: 403,
      message: '您没有审核权限'
    });
  }
  next();
}

module.exports = requireReviewRole;
```

这样即使有人通过某种方式绕过了通用RBAC中间件，也无法执行审核操作——因为审核路由额外加了这把锁。

## 七、踩坑记录

### 坑1：忘记给新板块配置权限矩阵

新增了「活动照片」板块后，忘了在`PERM_MATRIX`里加对应的配置。结果所有角色访问该板块都返回500错误（`undefined`上读取属性）。

**教训**：每次新增板块，必须同步更新三处：①数据库categories表 ② PERM_MATRIX ③ 前端导航栏配置。我后来写了个启动时的自检函数，如果检测到某个slug在矩阵中没有定义就打警告日志。

### 坑2：前端v-if判断依赖异步数据

页面加载时`user`对象还是`null`（从localStorage读取还没完成），导致权限相关的按钮先闪一下再消失。

**解决**：加一个`v-if="user"`在最外层容器，等用户信息加载完再渲染整个面板。

## 八、本篇小结

RBAC的核心思想是**"权限跟随角色，角色分配给人"**。我们的实现遵循三个原则：

1. **默认拒绝**：未显式授权的一律拒绝
2. **最小权限**：每个角色只给完成工作所需的最小权限集合
3. **前后端双检**：前端提升体验，后端保障安全

> 💡 **可复用经验**：这套RBAC模式（矩阵定义→中间件工厂→路由级粒度→前后端双检）可以直接移植到任何需要权限控制的Node.js项目中。
>
> **最终篇预告**：《从零搭建教学资源平台（七）：项目复盘——踩坑记录与优化建议》——汇总全系列所有坑点、性能优化方向和后续规划。这是收官之作，值得收藏。

**标签**：#WorkBuddy开发者分享季# #RBAC# #权限系统# #安全# #架构设计# #Node.js#

在项目的第一版设计中，我只有两个角色：「管理员」和「普通用户」。上线一周后就发现不够用了：

# 从零搭建教学资源平台（六）：RBAC四级权限控制系统 #WorkBuddy开发者分享季#

系列导航：本文是系列第六篇。前一篇讲了文件上传，本篇聚焦整个项目最复杂的模块——RBAC（基于角色的访问控制）。

后端

开发工具

架构设计

RBAC权限系统设计实战：从四级角色矩阵到前后端双重校验。通过teacher/staff/admin/superadmin四级角色划分，实现教学资料、学校管理、学生成绩、活动照片四大板块精细控制。包含权限矩阵数据结构、中间件实现、特殊场景处理及踩坑经验，适用于Node.js项目权限管理需求。

数据结构

代码解释

中间件

数据库

WorkBuddy 

容器

路由

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

# 从零搭建教学资源平台（六）：RBAC四级权限控制系统 #WorkBuddy开发者分享季#-腾讯云开发者社区-腾讯云

# 从零搭建教学资源平台（六）：RBAC四级权限控制系统 #WorkBuddy开发者分享季#

# 从零搭建教学资源平台（六）：RBAC四级权限控制系统 #WorkBuddy开发者分享季#

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐