资源权限： 菜单导航栏 & 页面 & 按钮 资源可见权限
数据权限： 对于页面上的数据操作 同一个人同一个页面 不同的数据 可能存在不同的数据操作权限
权限纬度
角色纬度 用户 => 角色 => 权限
用户纬度 用户 => 权限
表现形式
基础表现形式还是树结构的展现形式 因为对应的 菜单 - 页面 - 按钮 是一个数的从主干到节点的数据流向
XX
出于实际工作的需要，很多项目(尤其类似后台管理系统)需要引入权限控制.倘若权限架构设计的不好 或者没有涉及 会导致项目中各种权限代码混入业务代码 造成结构混乱,其次想给新模块引入权限控制或者功能扩展都会十分棘手.
虽然前段在权限层面能做一些事情,但是很遗憾真正对权限进行把关的是后端.例如一个软件系统,前端在不写一行代码的情况下,当用户进入到某个他无权访问的页面时,后端是可以判断他越权访问并拒绝返回数据的,由此可见 即使前端不做什么 整个系统也是可以正常运行的 但是这样应用的体验很不好.另外一个很重要的就是前端做的权限校验都是可以被本地数据造假越权通过的
前端如果能判断某用户越权访问页面时 就不要让他进入那张页面后在弹出无权访问的信息提示 因为这样体验会很差 最优方案是直接关闭那些页面的入口 只让他看他能够访问的内容 这样即使他通过输入路径恶意访问 导航最后也只会将它带到默认页面 || 404 page
前端做的权限控制大抵是先接受后台发送的权限数据 然后将数据注入到整个应用中 整个应用于是开始对页面的展现内容以及导航逻辑进行控制 从而达到权限控制的目的 前端做的权限控制虽然能提供一层防护 但根据目的还是为了优化体验
页面权限控制
页面权限控制要探讨的问题是 如何给不同角色赋予不同的页面访问权限
一旦软件系统引入了角色的概念 那么每个账户在注册之后就会被赋予相应的角色 从而拥有相应的权限 这里要注意 前端依据的客体是角色 不是某个账户 因为账户是依托于角色的 真正落地到前端项目中是不需要去处理角色逻辑的，那部分功能主要由后端完成
当用户登陆成功之后 通过接口返回值得知用户数和所属角色 拿到角色值后就去配置文件取出该角色所能访问的页面列表数组 （可在后端做对应配置） 随后将这部分数据加载到应用中从而达到权限控制的目的