飞布产品手册
官网B站Github
V2.0
V2.0
  • 序言
  • 更新日志
    • 更新日志V2.0
    • V2.0更新说明
    • 更新日志V1.0
  • 产品简介
    • 什么是飞布?
    • 飞布的价值
    • 飞布的优势
    • 应用场景
    • 数据安全
    • 产品案例
  • 快速入门
    • 初识飞布
    • 快速上手
      • 图文版
    • 词汇概览
    • 工作原理
  • 基础-可视化开发
    • 概览
      • CLI
      • 控制台
        • 主功能区
    • 数据源
      • 数据库
        • 数据库连接
          • 高级设置
        • 数据建模
        • 数据预览
      • Prisma 数据源
      • REST 数据源
      • GraphQL 数据源
      • 消息队列
    • API构建
      • 可视化构建
        • API规范
      • 批量新建
      • HTTP请求流程指令
      • 使用API
      • 实时查询
      • 实时推送
      • 关联查询
      • 数据缓存
      • 常见用例
    • 身份验证
      • 授权码模式
        • 身份验证(废弃)
      • 隐式模式
      • 数据权限控制
    • 身份授权
      • RBAC
        • 授权与访问控制(废弃)
      • 接口权限控制
      • 开放API
    • 文件存储
      • S3配置及使用
      • 文件管理面板
      • 高级配置:profile
  • 进阶-钩子机制
    • 钩子概览
    • 启动钩子
      • Node钩子
      • Golang钩子
      • Java钩子
      • Python钩子
    • OPERATION钩子
    • 身份验证钩子
    • graphql钩子
    • 函数钩子
      • function
      • proxy
    • 文件上传钩子
    • 内部调用
  • 使用-部署上线
    • 部署运维
      • 手动部署
        • 流水线部署(废弃)
      • Docker部署
      • 飞布云
      • sealos部署
    • 接口安全
      • CSRF token 保护
      • 跨域访问
    • 客户端SDK
      • Js SDK
      • 微信小程序SDK
      • Flutter SDK
      • uniapp SDK
    • 性能测试
  • 迁移到V2
  • 环境准备
    • 文件存储 S3
    • 身份认证 OIDC
    • NodeJs环境
  • 实战案例
    • Amis Admin
      • 管理后台-refine(废弃)
    • 实时TODO LIST
    • 语音版ChatGPT
    • AI魔法师实战
    • 阿里低代码引擎
    • appsmith集成
  • Roadmap
  • 常见问题
  • 核心概念
    • GraphQL
    • 超图
    • 请求时序图
    • 服务端Operation
  • 二次开发
    • 钩子规范
      • 钩子规范bak
    • 模板规范
    • 自定义模板
    • 其它参考
由 GitBook 提供支持
在本页
  • 添加指令
  • 指令介绍

这有帮助吗?

在GitHub上编辑
  1. 基础-可视化开发
  2. 身份授权

接口权限控制

@rbac指令

上一页授权与访问控制(废弃)下一页开放API

最后更新于1年前

这有帮助吗?

接下来,我们先学习如何在Fireboom中为权限绑定角色,实现该过程需要用到@rbac指令。

该指令为全局指令,作用于整个OPERATIN上。

添加指令

  1. 前往API管理面板,选择需要设置权限的API

  2. 在GraphQL编辑区的工具栏中点击“@角色”,选择匹配模式并添加角色,如添加admin角色

使用该指令后,有2个影响。

  1. 登录校验:用户登录后才能访问当前接口,这部分和单独在设置中开启授权功能一致。

  2. 权限控制:访问接口时,判断当前登录用户的角色是否与匹配规则一致,不一致时返回401错误。

指令介绍

该指令有4种类型的匹配规则,匹配规则本质上对应数学中集合的概念。

首先,需要知道三个集合域:

  • 全部角色:角色管理列表中配置的角色

  • 用户角色:用户拥有的角色,在钩子中为用户设置的角色

  • API角色:OPERATION上 @RBAC指令声明的角色

角色列表为全集,用户拥有的角色为其子集,API拥有的角色也是子集。

  • requireMatchAll:全部匹配,用户角色包含API角色时,可访问

  • requireMatchAny:任意匹配,用户角色与API角色有交集时,可访问

  • denyMatchAny:互斥匹配,用户角色与API角色互斥时,可访问

  • denyMatchAll:非全部匹配,当任意匹配或互斥匹配时,可访问

最后,以全部角色作为全集,结合四种关系,看用户角色和API角色的交并补情况,确定当前用户是否能访问当前API。

实际情况下,我们一般使用requireMatchAny匹配规则。

它表示角色拥有某些接口,当用户拥有该角色时,就能访问该接口,也即:用户通过角色拥有该角色的所有接口权限!和RBAC0规范一致!

一方面,一个角色会有多个接口。对应着就是,多个OPERTION使用requireMatchAny绑定同一个角色。

例如:A、B OPERATION都绑定了admin角色。

A.graphql
query A($id: Int = 1) @rbac(requireMatchAny: [admin]) {
  todo_findUniqueTodo(where: {id: $id}) {
    completed
    createdAt
    id
    title
  }
}
B.graphql
query B($id: Int = 2) @rbac(requireMatchAny: [admin]) {
  todo_findUniqueTodo(where: {id: $id}) {
    completed
    createdAt
    id
    title
  }
} 

反过来,一个接口也会属于多个角色。对应就是,一个OPERTION使用requireMatchAny绑定了多个角色。

例如:C OPEARTION绑定了admin和user角色。

C.graphql
query C($id: Int = 3) @rbac(requireMatchAny: [admin, user]) {
  todo_findUniqueTodo(where: {id: $id}) {
    completed
    createdAt
    id
    title
  }
}
  • 如果,用户只拥有admin角色,它就能访问A、B、C三个接口

  • 如果,用户只拥有user角色,就只能访问C接口。

全部角色