前端权限控制的一些思考

最近手头上同时做着两个项目：一个前端使用的是React，一个则是微信小程序。看似相差挺大，实质是一样的交互方式。不过，前端开发大概率绕不过的一个功能就是权限校验了。对于后台管理类的应用或许可以粗粒度地从模型级别（对应数据库的每一张表）来隔离，但对于服务C端的应用来说就要更细粒度地针对对象级别（对应表的每一条记录）的隔离了。

坦白说，所有校验工作在后端一定是有的，那为什么还要费老大劲在前端再做一次呢？就这个问题我能想到的一点解释是：如同表单提交一样，先在前端进行简单的拦截（或隐藏）工作在一定程度上可以减少一些无效的请求以缓解服务器压力。当然，应该还有一些其他更重要的考量，也欢迎一起探讨。

回到前端权限校验的话题。大抵可以从三个层面来考虑： 1, 针对路由（或页面）的权限校验；2，针对功能模块的权限校验；3，针对单条记录的权限校验。拿React来说，前两条的处理方式实际是一样的，无非是粒度大小的问题。比如要控制某条路由是否可访问，实质就是控制相应组件的访问权限。那么问题就简单了，我们可以给组件作一层wrapper，然后在wrapper中进行判断以决定是否显示组件或跳转到403页面。对于单条记录的访问控制，就我个人理解，是为了让记录的关联用户能够访问和处理该记录，但又不能放开全部记录。一种做法可能是在权限校验的基础上再加上一条用户信息比对，如此一来就需要前端缓存已登录用户的信息。以上的解决方式大多会通过前端缓存用户的权限列表实现。如果用户的权限被修改了，有可能会导致前后端数据不一致。当然，如果不缓存的话，就得频繁调用权限接口。那么，另一种做法就是把这项工作全部仍给后端来做，对于每个数据模型或者每条数据记录的请求后端都会给出校验后的结果，前端拿到数据后判断是否可访问某些功能。这样会增加请求的数量，如果并发量大的话可能会对服务器带宽造成额外的损耗。比如，对于单条记录的更新和删除权限其实可以附着在常规的数据请求中，但新增和查看操作却要在获取记录前就得知道权限数据，需要提前单独做一次请求。

前端做数据缓存会减少不必要的请求，但会出现数据不一致问题。不过，这并比影响系统的安全性。而如果由后端来提供权限数据，则会造成不必要的浪费。当然，对于一个并发量很高的应用来说，是不是可以采用单独的权限认证服务器专门负责权限验证呢？类似场景我尚未遇到，也很难找到其处理的边界。不过，未来倒是可以做一些尝试。