1.权限跟数据结构都是通过数据库控制
2.admin管理员可以对文件夹进行授权是否可以访问,若设置一个用户甲可以访问a文件夹下的子文件夹b,则用户甲可以访问文件夹a,但是甲用户界面只显示他有权限访问的b文件夹,a文件中的其他文件夹或文件甲用户看不见也无法访问。
3.操作文件都是通过数据库实现
4.底层数据库怎么设计
设计思路
1、一个tbl_admin表,用来创建admin账号
2、一个权限表tbl_permission,用来创建权限,比如每一行权限,如果访问文件夹的话,以Json字段的形式存储,可以访问的文件夹标记true,不可以的false
3、一个用户表tbl_user,用来创建普通用户
4、一个用户权限关系表tbl_user_permission,用来帮顶普通用户和权限的关系
// tbl_permission: 权限表
id
name 用来存储权限名字
permission 用来存储权限字段 Json格式,
比如://这个只是举了个例子,可以根据自己需求简化这个json字段和结构
{
"a":{
"data": {
"b": {
"data":{
"b_sub_dir": {
},
"flag": false
}
},
"flag": true,
}
}
}
// tbl_user; 用户表
id
name
// tbl_user_permission 用户权限表
id
user_id
permission_id
后端接口加个权限验证,
每次用户想要通过前端调用某个接口的时候,
1、后端接口获取用户id或者session或其他
2、根据用户id来去 用户权限表tbl_user_permission 里获取用户权限,然后对那个Json格式的权限字段进行解析处理
判断这个用户是否有权限进行这个接口的访问,或者对这个文件夹的访问
前端根据返回结果进行渲染,
如有问题及时沟通
我要的是数据库的设计以及实现流程
我抛块砖 比较笨 但是可以做到目录级别或者文件级别的访问限制:
这个跟菜单权限不是一模一样吗,用户,用户角色,角色,角色菜单 , 菜单(权限);
没有角色的概念就直接直接 用户,用户菜单,菜单
用户表、角色表、用户角色表、角色权限表。
角色权限表中建立角色和文件访问权限的关系。