前端权限控制的本质
一般说来，权限管理可以分为两种情况：
第一种为页面级访问权限。第一种情况是非常常见的，即用户是否能够看到页面；
第二种为数据级操作权限。第二种情况是用户能否对数据进行增删改查等操作。
这两种情况在实际的前端表现中都是一致的，即用户在正常页面中看不见，看不见就不能操作，所以进行了一次视觉上的隔离。在这里有的人可能会说：“你这不是自欺欺人吗？视觉隔离有什么用啊，有好多方法能够绕过去的啊，比如改改代码或者直接用ajax访问”。是的，你说的对，这其实就是自欺欺人，不过这也正是我要说的：前端的权限控制实质上就是用于展示，让操作变得更加友好，真正的安全实际上是由后端控制的。
这里举个例子简单说明一下。如果用户通过其他方式绕过了前端的路由控制，访问到了该用户原本不能访问的页面，然后呢？页面中的数据需要从后端获取，页面中的操作也需要发送给后端，如果后端自身对于所有的请求接口有自己的权限控制，那么用户其实只能看到这个页面中固有的那些信息。
这里其实还有一个大家很容易想到的问题：在做接口测试时，如果系统本身有权限设置，但是接口未做权限，那么测试直接使用API测试工具访问的话…呵呵。所以说前端根本不用纠结于用户以各种形式绕过页面的问题，而以上这些问题在后端那里则根本不是问题。
权限策略
在理解了前端权限的本质后，我们说一下前端的权限策略。依照我目前的了解，大致上把权限策略分为以下两种：
1.前端记录所有的权限。用户登录后，后端返回用户角色，前端根据角色自行分配页面。优点是前端完全控制，想怎么改就怎么改；缺点是当角色越来越多时，可能会给前端路由编写上带来一定的麻烦。
2.前端仅记录页面，后端记录权限。用户登陆后，后端返回用户权限列表，前端根据该列表生成可访问页面。优点是前端完全基于后端数据，后期几乎没有维护成本；缺点是为了降低维护成本，必须拥有菜单配置页面及权限分配页面，否则就是噩梦。
本篇采用第二种方式：接口权限控制
上文中说到，前端权限控制中，真正能实现安全的是接口，所以先实现接口的权限控制，而且这里听上去很重要，但实际上却很简单。接口权限控制说白了就是对用户的校验。正常来说，在用户登录时服务器应给前台返回一个token，以后前台每次调用接口时都需要带上这个token，服务端获取到这个token后进行比对，如果通过则可以访问。
我们通过对axios进行简单的设置，增加请求拦截器，为每个请求的Header信息中增加Token。以下为伪代码：
const service = axios.create()
// http request 拦截器
// 每次请求都为http头增加Authorization字段，其内容为token
service.interceptors.request.use(
config => {
config.headers.Authorization = `${token}`
return config
}
);
export default service
这样简单的设置后即可实现在每次接口权限控制的前端部分。
接下来则是分别讲述“页面级访问控制”和“数据级操作控制”的前端实现方式。如果对数据级操作控制不感兴趣的可以直接跳过。
页面级访问权限控制
虽然页面级访问控制实质上应该是控制页面是否显示，但落在实际中则有两种不同的情况：
1.显示系统中所有菜单，当用户访问不在自己权限范围内的页面时提示权限不足。
2.只显示当前用户能访问的菜单，如果用户通过URL进行强制访问，则会直接404。
至于第一种形式，个人认为在用户体验上非常不好，但不排除有某些特殊场景会用到这种方式。而本篇的权限控制是基于第二种形式。
依据刚才选定的方式，及上文中提到的权限策略，我们能够联想并梳理出一个大致的流程，这也是本篇中实际权限的流程：
登录 ——> 获取该用户权限列表 ——> 根据权限列表生成能够访问的菜单 ——> 点击菜单，进入页面
数据级操作权限控制
数据操作权限的获取方式，我能够想到的是以下两种：
用户登录后，获取权限列表时，直接在该数据中体现
每次访问页面时请求后台，获取该页面的数据操作权限列表
不管项目中具体采用哪一种方法，或者使用两种方法的结合，其实现原理都是一样的：即将返回的数据操作权限列表增加到路由表中的对应页面的自定义字段中（如permission），然后在进入页面前，根据该自定义字段来判断页面中的元素是否需要显示。
这里的核心点是：如何将数据放置到路由表中，以及如何根据路由表中的字段在页面中进行判断
忘记出处，以前笔记中摘录，侵删。
