如何设计一个权限系统

https://www.cnblogs.com/cxydmx/p/11774474.html
image.png
权限是用户可以访问的资源,包括页面权限,操作权限,数据权限:

  • 页面权限: 即用户登录系统可以看到的页面,由菜单来控制,菜单包括一级菜单和二级菜单,只要用户有一级和二级菜单的权限,那么用户就可以访问页面
  • 操作权限: 即页面的功能按钮,包括查看,新增,修改,删除,审核等,用户点击删除按钮时,后台会校验用户角色下的所有权限是否包含该删除权限,如果是,就可以进行下一步操作,反之提示无权限。有的系统要求”可见即可操作”,意思是如果页面上能够看到操作按钮,那么用户就可以操作,要实现此需求,这里就需要前端来配合,前端开发把用户的权限信息缓存,在页面判断用户是否包含此权限,如果有,就显示该按钮,如果没有,就隐藏该按钮。某种程度上提升了用户体验,但是在实际场景可自行选择是否需要这样做
  • 数据权限（后端控制）: 数据权限就是用户在同一页面看到的数据是不同的,比如财务部只能看到其部门下的用户数据,采购部只看采购部的数据,在一些大型的公司,全国有很多城市和分公司,比如杭州用户登录系统只能看到杭州的数据,上海用户只能看到上海的数据,解决方案一般是把数据和具体的组织架构关联起来,举个例子,再给用户授权的时候,用户选择某个角色同时绑定组织如财务部或者合肥分公司,那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。
  • 创建菜单（每个菜单下面包含不同的权限（页面权限和操作权限））
  • 创建角色并绑定权限（角色有哪些权限、是否有轮转关系、组织架构变更关系…）
  • 给角色增加员工（给对应的角色增加员工（批量导入、按照组织架构、按照职位））

中间人劫持，怎么防止。x-frame-option?白屏的喔，怎么办？也不一定嵌入iframe啊，可以嵌入脚本、图片，怎么阻止

x-frame-option、重定向、https，请求前加密（https、加密代理）、请求中规避（请求拆包）、请求后弥补（前端做一些逻辑）。嵌入非iframe的，如果已经突破了前面两关，走前端逻辑：触发DOMNodeInserted、DOMContentLoaded、DOMAttrModified事件。或者是给能src的标签加上自己的data-xx属性标记区分。

当主机A、和机B通信时，都由主机C来为其“转发”，而A、B之间并没有真正意思上的直接通信，他们之间的信息传递同C作为中介来完成，但是A、B却不会意识到，而以为它们之间是在直接通信。这样攻击主机在中间成为了一个转发器，C可以不仅窃听A、B的通信还可以对信息进行篡改再传给对方，C便可以将恶意信息传递给A、B以达到自己的目的。

一般能防MITM的要具有以下特征：

  • 1、握手加密而且具有可信CA（SSL、TLS之类，CNNIC和WoSign就不点评了）或拥有预协商密钥（L2TP）
  • 2、加密方法足够强大（AES、CHACHA20之类，RC4和SM2就不点评了）

综上，一般情况下，以下的协议是安全的：

  • 1、HTTPS（排除RC4、3DES算法，排除CNNIC、WoSign的CA证书）
  • 2、OpenVPN（基于TLS，只要你能连上就是安全的）
  • 3、L2TP Over IPSec（必须要Over IPSec，没了就没加密了）
  • 4、IKEv2（基于TLS和可信CA发的证书，安全性比OpenVPN还好）
  • 5、SSTP（基于TLS和可信CA发的证书，安全性和IKEv2相同，稳定性加强，用443端口）
  • 6、ShadowSocks（基于N+1种加密算法，只要你不选RC4或RC4-MD5算法就是安全的）
  • 7、任何用SSL Stream过又验证CA甚至客户端证书的TCP连接（UDP大家都懂，DNS什么的）

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 , 或者 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌套到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。

1、DENY
表示该页面不允许在frame中展示，即便是在相同域名的页面中嵌套也不允许。
2、SAMEORIGIN
表示该页面可以在相同域名页面的frame中展示。
3、ALLOW-FROM uri
表示该页面可以在指定来源的frame中展示。
换一句话说，如果设置为DENY，不光在别人的网站frame嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为SAMEORIGIN，那么页面就可以在同域名页面的frame中嵌套。正常情况下我们通常使用SAMEORIGIN参数。

class 组件和 function 组件对比

  1. 使用class关键字创建的组件，有自己的私有数据（this.state）和生命周期函数；
  2. function组件每次渲染都会有独立props/state,而class组件总是会通过this拿到最新的props/state
  • class组件实例化一次，使用到的props/state都是通过this去获取，而this是可变的(mutable),所以在生命周期中所拿到的都是最新的props/state。

function组件每次渲染都会执行一次，每次渲染都有这次渲染所对应的独立的props/state。
所以在一些特殊情况下，class组件就会有错误的表现，比如点击一个延时输出状态的按钮，在延时输出结果之前去更改状态，最终结果总是最新修改的状态，而不是点击延时按钮时的状态。就像Dan的文章函数式组件与类组件有何不同？中所举的例子。

  • function组件逻辑聚合，而class组件逻辑分散

class组件中的生命周期绝大部分的工作是在不同的时刻去处理一些副作用，而function也需要一种机制去处理组件交互过程中的副作用，这就是useEffect。

class组件中可能会将同一个功能的逻辑拆分到不同的生命周期中，比如会在componentWillUnMount中去卸载定时器
业务 - 图2
再比如在每次传入的props发生变化时去执行副作用就需要在componentDidMount和componentDidUpdate两个生命周期中去写对应的逻辑
业务 - 图3
而在function组件中，上面同样的逻辑使用useEffect去处理副作用就会使得逻辑十分聚合，不会将同一模块的逻辑散落到不同的地方。
业务 - 图4
业务 - 图5

3. function组件逻辑复用简单，而class组件逻辑复用困难

在class组件中，逻辑复用的方案包括HOC和render props,但是这类方案都是将逻辑封装到一个抽象层的组件中，在使用多个复用逻辑时会形成抽象层组件的“嵌套地狱”。
例如一个组件需要复用鼠标位置逻辑和window size 变化的逻辑，让我们来对比下HOC、render props和hooks之间的逻辑复用
1. render props
业务 - 图6
React DevTools 中对应的组件
业务 - 图7
2. HOC
业务 - 图8
React DevTools 中对应的组件
业务 - 图9
3. hooks
业务 - 图10
React DevTools 中对应的组件
业务 - 图11
可以看出HOC和render props都会改变原先的组件结构，而hook可以使你在无需修改组件结构的情况下复用状态逻辑，并且在一个组件使用多个复用逻辑的情况下，hooks清晰简洁的逻辑提取和使用方式更能体现出优势。