前后端分离模式下的权限控制方案

在前后端分离的模式下,所有的交互场景都变成了数据交互,因此传统业务系统中的权限控制方案在前端已经不再适用(比如使用后台模板标签进行权限控制),需要另外设计权限控制方案。

权限控制的概念

要理解权限控制,需要明白两个概念:资源和权限。

资源:对于一个系统来说,系统内部的所有信息都可以理解为是这个系统的资源。页面是资源、数据是资源、按钮是资源、图片也是资源。

权限:权限就是访问某个资源所需要的标识。无论系统的权限如何设计,在用户登陆的时候都需要计算当前登陆用户所拥有的权限标识集合,这样才能确定这个用户所能访问的系统资源。

由上面可以得出,权限控制是控制登陆用户对于系统资源的访问。

前后端在权限控制中各自的职责

要弄清前后端在权限控制中各自的职责,需要明白前后端在系统中各自的职责。

服务端:提供数据接口。

前端:路由控制、页面渲染。

由于前端负责与用户交互,这就意味着,用户所能操作的资源入口就都是由前端进行控制,那么前端的权限控制就包括了前端路由的权限控制和页面内组件的权限控制。

前端路由的权限控制:过滤非法请求,用户只能访问权限范围之内的页面资源。

页面内组件的权限控制:根据用户的权限控制页面组件的渲染,包括各种按钮、表格和分割线等。

随着前端组件化的快速发展,用户所看到的一切都可以理解为组件。页面是一个大组件,其内部由各种小组件拼凑而来,那么前端权限的控制最终就落地到了对组件的权限控制。

<组件 permission=‘xxx‘ />

这样,前端就可以渲染出用户权限范围内的各种系统资源。但是却不能保证数据接口的安全性,因为某些比较喜欢折腾的用户完全可以越过前端的页面访问系统的数据接口。服务端的权限控制最终还是要落地到对接口的权限验证。

简单实现

理论上来说,系统的一切资源都是可以进行权限控制的,实际上也可以做得到,只是实际场景中并不需要细化到页面上一条分割线这种程度,最细的粒度一般只是到按钮级别。

前端

前端路由权限控制,可以通过在用户登陆的时候存储在前端的用户所拥有的权限标识集合,在路由变化时进行权限判断。具体是,权限验证通过则渲染对应页面,否则渲染403组件。

let hasPermission = permission.check(current.permissionName);

<div className={styles.content}>
    {hasPermission ? children : <Exception type={403}/>}
</div>

服务端

服务端的权限验证很好理解,一个最简单的实现是使用拦截器验证当前请求的权限。

public class SsoAuthorizeInterceptor extends HandlerInterceptorAdapter {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 校验权限
    }
}

总结

所有业务组件的设计理念均是要结合服务端接口进行组件的封装,兼顾灵活性的同时可以保证更优的业务开发速度。

"不可能实现的诺言最动人。"

原文地址:https://www.cnblogs.com/yanggb/p/11370869.html

时间: 2024-08-08 07:22:36

前后端分离模式下的权限控制方案的相关文章

AngularJS中在前后端分离模式下实现权限控制 - 基于RBAC

权限的设计中比较常见的就是RBAC基于角色的访问控制,基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合.每一种角色对应一组相应的权限. 一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限.这样做的好处是,不必在每次创建用户时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,这样将简化用户的权限管理,减少系统的开销. 在Angular构建的单页面应用中,要实现这样的架构我们需要额外多做一些事

前后端分离模式

我是做java出身的前端开发工程师经历过由前端视图逻辑和后端的业务逻辑混合的开发模式, 在到由ajax跨域请求来进行前后端的分离的模式,最后到由nodejs来进行前后端的分离, 今天就分别站在不同的视角上尽可能的为大家剖析下这几种模式的优缺点. 前后端逻辑混合开发模式: 这种开发模式在现在来看几乎没有什么优点,但是在很多互联网公司依然在用,我想这大概是历史原因造成的吧, 也有可能缺乏技术体系的整体思想,但是也不能完全否定其优点,与第二种开发模式相比较. 优点: 1. 用户体验好,在相同的网络条件

在前后端分离的SpringBoot项目中集成Shiro权限框架

项目背景 公司在几年前就采用了前后端分离的开发模式,前端所有请求都使用ajax.这样的项目结构在与CAS单点登录等权限管理框架集成时遇到了很多问题,使得权限部分的代码冗长丑陋,CAS的各种重定向也使得用户体验很差,在前端使用vue-router管理页面跳转时,问题更加尖锐.于是我就在寻找一个解决方案,这个方案应该对代码的侵入较少,开发速度快,实现优雅.最近无意中看到springboot与shiro框架集成的文章,在了解了springboot以及shiro的发展状况,并学习了使用方法后,开始在网上

基于 koajs 的前后端分离实践

一.什么是前后端分离? 前后端分离的概念和优势在这里不再赘述,有兴趣的同学可以看各个前辈们一系列总结和讨论: 系列文章:前后端分离的思考与实践(1-6) slider: 淘宝前后端分离实践 知乎提问: 如何评价淘宝 UED 的 Midway Framework 前后端分离? Web 前后端分离的意义大吗? 尤其是<前后端分离的思考与实践>系列文章非常全面的阐述了前后端分离的意义和技术实现.如果不想看上面的文章,可以在脑海里留下这样一个轮廓就好: 本文主要阐述趣店团队基于Koajs的前后端分离实

前后端分离后台api接口框架探索

前言 很久没写文章了,今天有时间,把自己一直以来想说的,写出来,算是一种总结吧!  这篇文章主要说前后端分离模式下(也包括app开发),自己对后台框架和与前端交互的一些理解和看法.     前后端分离,一般传递json数据,对于出参,现在通用的做法是,包装一个响应类,里面包含code,msg,data三个属性,code代表状态码,msg是状态码对应的消息,data是返回的数据. 如  {"code":"10008","message":"

关于Web实现前后端分离,前后端解耦

一.前言 ”前后端分离“已经成为互联网项目开发的业界标杆,通过Tomcat+Ngnix(也可以中间有个Node.js),有效地进行解耦.并且前后端分离会为以后的大型分布式架构.弹性计算架构.微服务架构.多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础. 前后端分离(解耦)的核心思想是:前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互. 注:[在互联网架构中,web服务器:一般指像nginx,apache这类的服务器,他们一般只

【转】Web实现前后端分离,前后端解耦

一.前言 ”前后端分离“已经成为互联网项目开发的业界标杆,通过Tomcat+Ngnix(也可以中间有个Node.js),有效地进行解耦.并且前后端分离会为以后的大型分布式架构.弹性计算架构.微服务架构.多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础. 前后端分离(解耦)的核心思想是:前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互. 注:[在互联网架构中,web服务器:一般指像nginx,apache这类的服务器,他们一般只

架构设计:前后端分离之Web前端架构设计

在前面的文章里我谈到了前后端分离的一些看法,这个看法是从宏观的角度来思考的,没有具体的落地实现,今天我将延续上篇文章的主题,从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案,该方案和我原来设想有了很大的变化,但是核心思想没变,就是控制层是属于Web前端的. 在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分,原方案的构想在实际的生产开发里很难做到,我觉得核心还是控制层和视图层的技术异构性,这样后果使得系统改造牵涉面太大,导致在项目团队里,沟通.协调以及管理成本相对较高,

基于NodeJS的全栈式开发(基于NodeJS的前后端分离)

也谈基于NodeJS的全栈式开发(基于NodeJS的前后端分离) 前言 为了解决传统Web开发模式带来的各种问题,我们进行了许多尝试,但由于前/后端的物理鸿沟,尝试的方案都大同小异.痛定思痛,今天我们重新思考了“前后端”的定义,引入前端同学都熟悉的NodeJS,试图探索一条全新的前后端分离模式. 随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制的版本.为了提升开发效率,前后端分离的需求越