关于接口权限控制以及rbac

简介: 关于接口权限控制以及rbac

分端实现权限控制

最常见的接口权限控制就是分端形式了,不同的端实现不同的接口,一个用户登录后,只能访问这个端的接口,而不能去访问其他端的接口.

例如:

商城有商家端,管理端,买家端,各个端之间账号互不相通.

每个端对订单的操作逻辑也不一样

用户端只能新建,查看订单

商家端只能查看订单,发货订单

管理端只能查看订单

代码结构大致为:

├── Admin  管理端
│   └── Order  订单
│       └── getList  查看订单列表
├── Shop  商家端
│   └── Order  订单
│       ├── deliver  发货
│       └── getList  查看订单列表
└── User 管理端
    └── Order  订单
        ├── add  新增订单
        └── getList 查看订单列表

这种权限控制的方法优点为:  通俗易懂,容易维护,项目复杂度不高,可以根据不同端来响应不同的字段

但是需要写更多的代码(查看订单写了3份,每次有字段改动都需要改动3份)

适合用户角色较少,分级明显的项目  (适合大多数项目)

rbac 权限控制

rbac其实百度已经很多了,我这边就大概说明下定义.

RBAC基于角色的访问控制(Role-Based Access Control )

按代码的方式来讲就是:

给角色赋予不同的权限,再通过给用户赋予不同的角色,来实现不同的权限控制.

例如 在一个企业中的货物管理系统中.

可能存在:

管理员:可操作所有权限

财务:管理货物价格

货物出入库管理员:货物出入库

货物主管:审核出入库

职工:申请货物

多个角色,如果按照分端来做的话,就需要分5个端甚至更多,同时查看货物的功能就需要写5份相同的代码.

这个时候,我们可以通过rbac权限控制的方法来做

代码结构为:

└── User  所有角色都是用户,需要登陆,通过数据库授权
    ├── Apply  
    │   ├── add    职工
    │   ├── getList  职工,货物主管
    │   └── verify   货物主管
    └── Goods 
        ├── add    管理员
        ├── getList  货物管理员,财务,职工,货物主管
        ├── takeOut  职工,货物主管
        ├── update   管理员
        ├── updatePrice 财务
        └── updateNum  货物管理员

我们可以给一个用户赋予多个角色,例如职工也可能是货物主管,也可能还是货物管理员等等

通过这种多重角色赋予,角色授权模式,可以更好的动态赋予权限

完善方法,响应参数控制

那么这样就行了吗?

不,上面的是一个demo.并不完整

假设

在Goods/getList 中,不允许职工看到价格,只允许财务看到,

那么该怎么实现?

很明显,最简单的方法就是,写一个 getListForStaff再写一个 getListForFinance

那么又会问了,既然方法还是要写这么多,那rbac权限控制还有存在的必要吗?

rbac除了可以省几个通用方法之外,最重要的一点是用户多角色授权,所以还是有必要的

rbac实现步骤

#### role_list 角色表
- roleId \`int 11\`
- roleName \`varchar 32  \`
#### user\_role\_relation_list 用户角色关联表 (多对多)
- relationId \`int\`
- userId \`int\`
- roleId \`int\`
#### permission_list 权限表
- permissionId \`int\`
- permissionName \`varchar 64\`
- url \`varchar 64  /Api/User/add \`
#### role\_permission\_relation_list 角色权限关联表
- relationId \`int\`
- roleId \`int\`
- userId \`int\`
- permissionId \`int\`
- authorizeType \`tinyint 1正向授权 2反向授权\`

主要表为这4个表,通过对用户授权角色

用户,角色间的权限关联叠加(反向授权>正向授权) 得到最后的权限列表,进行判断

此为后端表现形式,但是因为前端需要做管理菜单 显示/隐藏 等,所以还需要附带一个菜单管理功能:

#### menu_list 菜单表
- menuId \`int 菜单id\`
- menuName \`varchar 菜单名称\`
- permissionId \`int 授权id (如果为0则代表不受权限控制管理)\`
- url \`varchar\`
- pid \`int 父级id\`
- level \`tinyint 菜单等级\`
- displayMenu \`tinyint 是否显示菜单 有些 更新/新增 权限明显不是菜单,不需要显示出来\`

流程图:

image.png

目录
相关文章
|
存储 缓存 负载均衡
Nginx入门笔记
Nginx入门笔记
503 0
|
存储 Java 测试技术
|
6月前
|
弹性计算 机器人 应用服务中间件
AppFlow支持Qwen3开源版本调用
近期,Qwen3正式发布并开源全部8款“混合推理模型”,包括两款MoE模型(Qwen3-235B-A22B与Qwen3-30B-A3B)和六个Dense模型。目前,AppFlow已支持上述所有模型调用,您可在钉钉或微信等多渠道使用这些模型满足业务需求。本文将介绍如何配置及集成这些模型至钉钉机器人和企业微信应用中,包括创建应用、设置权限、生成连接流以及配置相关参数的详细步骤。完成配置后,用户可通过钉钉或企业微信直接与Qwen3应用互动交流。
222 6
AppFlow支持Qwen3开源版本调用
|
6月前
|
存储 JavaScript 前端开发
基于 ant-design-vue 和 Vue 3 封装的功能强大的表格组件
VTable 是一个基于 ant-design-vue 和 Vue 3 的多功能表格组件,支持列自定义、排序、本地化存储、行选择等功能。它继承了 Ant-Design-Vue Table 的所有特性并加以扩展,提供开箱即用的高性能体验。示例包括基础表格、可选择表格和自定义列渲染等。
450 6
|
9月前
|
存储 设计模式 Java
探索 JavaBean(实体类)的奇妙世界
JavaBean(实体类)是Java开发中的重要概念,遵循特定设计模式的普通Java类。
466 13
|
前端开发 API 调度
React 之从 requestIdleCallback 到时间切片
在上篇《React 之 requestIdleCallback 来了解一下》,我们讲解了 requestIdleCallback 这个 API,它可以实现在浏览器空闲的时候执行代码,这就与 React 的理念非常相似,都希望执行的时候不影响到关键事件,比如动画和输入响应,但因为兼容性、requestIdleCallback 定位于执行后台和低优先级任务、执行频率等问题,React 在具体的实现中并未采用 requestIdleCallback,本篇我们来讲讲 React 是如何实现类似于 requestIdleCallback,在空闲时期执行代码的效果,并由此讲解时间切片的背后实现。
552 0
|
12月前
|
存储 数据可视化 API
API接口数据获取流程的细化
本文概述了API的基础知识、获取API访问权限的方法、编写代码调用API的步骤、数据处理与分析技巧以及数据安全与合规的重要性,并提供了社交媒体数据分析、天气预报应用和电商数据分析等API数据获取的应用实例,旨在帮助读者全面了解和实践API接口数据获取的流程。
|
监控 安全 网络安全
Windows系统安全深度解析:挑战、策略与全面防护
对敏感数据进行加密是保护数据机密性的重要手段。使用强加密算法对敏感数据进行加密存储和传输,即使数据被窃取也无法被轻易解密。此外,还可以考虑使用全磁盘加密技术来保护整个系统的数据安全性。
vue 中 axios 的安装及使用
本文介绍了在Vue项目中安装和使用axios的方法。首先通过命令`npm install axios --save-dev`安装axios,然后在组件的`created`生命周期钩子中使用`axios.get`异步获取数据,并将获取的数据更新到组件的`data`中。文中提供了完整的示例代码,包括安装命令、验证安装成功的步骤、Vue组件的模板、脚本和样式。
vue 中 axios 的安装及使用
|
SQL 缓存 运维
Sql Server日常运维看我这篇就够了!
Sql Server日常运维看我这篇就够了!
491 2