邻居少妇张开腿让我爽了一夜视频,乱妇熟妇乱女xxx,麻豆av一区二区三区久久

SpringBoot實(shí)現(xiàn)RBAC權(quán)限校驗(yàn)?zāi)Ｐ偷氖纠?/h1>

更新時(shí)間：2025年04月10日 09:38:46 作者：陌路物是人非

本文主要介紹了SpringBoot實(shí)現(xiàn)RBAC權(quán)限校驗(yàn)?zāi)Ｐ偷氖纠?文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧

不過(guò)這次我做的項(xiàng)目是個(gè)后臺(tái)管理系統(tǒng)，主要是自己和朋友使用，所以角色其實(shí)就分成了管理員和普通用戶(hù)，因此我省略掉了角色和角色權(quán)限表，這樣雖然不夠靈活，但畢竟使用的人少，所以管理起來(lái)也非常方便

數(shù)據(jù)庫(kù)表

數(shù)據(jù)庫(kù)主要?jiǎng)?chuàng)建三張表

用戶(hù)表:

主要用來(lái)使用用戶(hù)登錄

id 用戶(hù)主鍵
account 登錄賬號(hào)
password 登錄密碼
type 區(qū)分普通角色和管理員身份
username 用戶(hù)名
status 用戶(hù)的狀態(tài)

+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int         | NO   | PRI | NULL    | auto_increment |
| account   | char(15)    | YES  |     | NULL    |                |
| password  | varchar(50) | YES  |     | NULL    |                |
| type      | int         | YES  |     | NULL    |                |
| username  | varchar(20) | YES  |     | NULL    |                |
| status    | int         | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+

權(quán)限表:

主要用來(lái)記錄權(quán)限信息

id 權(quán)限主鍵
name 權(quán)限名稱(chēng)
parent_id 父權(quán)限的id 如果沒(méi)有父權(quán)限則為null
status 權(quán)限是否啟用
remark 權(quán)限備注
level 權(quán)限的層級(jí)，主要用來(lái)排序的字段

+-------------+-------------+------+-----+---------+----------------+
| Field       | Type        | Null | Key | Default | Extra          |
+-------------+-------------+------+-----+---------+----------------+
| id          | int         | NO   | PRI | NULL    | auto_increment |
| name        | varchar(20) | YES  |     | NULL    |                |
| parent_id   | int         | YES  |     | NULL    |                |
| status      | int         | YES  |     | NULL    |                |
| remark      | varchar(50) | YES  |     | NULL    |                |
| create_user | int         | YES  |     | NULL    |                |
| create_date | date        | YES  |     | NULL    |                |
| update_user | int         | YES  |     | NULL    |                |
| update_date | date        | YES  |     | NULL    |                |
| level       | int         | YES  |     | NULL    |                |
+-------------+-------------+------+-----+---------+----------------+

用戶(hù)權(quán)限表:

實(shí)現(xiàn)多對(duì)多關(guān)系的表

id 主鍵
user_id 用戶(hù)的ID
permission_id 權(quán)限的ID

+---------------+------+------+-----+---------+----------------+
| Field         | Type | Null | Key | Default | Extra          |
+---------------+------+------+-----+---------+----------------+
| id            | int  | NO   | PRI | NULL    | auto_increment |
| user_id       | int  | YES  | MUL | NULL    |                |
| permission_id | int  | YES  |     | NULL    |                |
+---------------+------+------+-----+---------+----------------+

主要解釋下權(quán)限表，因?yàn)楣芾硐到y(tǒng)需要根據(jù)權(quán)限判斷是否提供菜單，因此我將菜單作為了一級(jí)權(quán)限(parent_id=null)，一級(jí)權(quán)限下的增刪改查等操作定義為二級(jí)權(quán)限(parent_id=對(duì)應(yīng)的一級(jí)權(quán)限)

如果用戶(hù)擁有某些權(quán)限就在用戶(hù)權(quán)限表中創(chuàng)建一條記錄

后端實(shí)現(xiàn)

后端實(shí)現(xiàn)起來(lái)非常的方便，我使用的方法是定義一個(gè)注解通過(guò)AOP掃描這個(gè)注解，然后判斷當(dāng)前用戶(hù)是否擁有對(duì)應(yīng)的權(quán)限，如果沒(méi)有直接拋出異常，通過(guò)全局異常處理器進(jìn)行捕捉

定義注解類(lèi):

因?yàn)楹笈_(tái)管理實(shí)現(xiàn)的非常簡(jiǎn)單，幾乎不存在多個(gè)表之間相互嵌套，因此我用了個(gè)value表示當(dāng)前Controller需要使用到的權(quán)限的ID

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface PermissionCheckAnnotation {
    int value();
}

定義枚舉類(lèi):

主要用來(lái)定義對(duì)應(yīng)權(quán)限的ID值

public class PermissionEnum {
    public final static int USER_QUERY = 14;
    public final static int USER_UPDATE = 15;
    public final static int USER_CREATE = 16;
}

定義AOP切面

    @Pointcut("execution(掃描當(dāng)前包中的全部文件) && @annotation(annotation.PermissionCheckAnnotation)")
    public void pt(){}

    @Around("pt()")
    public Object PermissionCheck(ProceedingJoinPoint jp) throws Throwable {
        MethodSignature signature = (MethodSignature) jp.getSignature();
// 反射拿到權(quán)限ID
        PermissionCheckAnnotation annotation = signature.getMethod().getAnnotation(PermissionCheckAnnotation.class);
        int value = annotation.value();
        // 獲取用戶(hù)ID
        Integer userId = UserContext.getUserId();
        // 查詢(xún)當(dāng)前用戶(hù)和權(quán)限ID之間是否存在關(guān)聯(lián)關(guān)系，如果不存在拋出異常
        Integer hasPermission = userPermissionMapper.hasPermission(value, userId);
        if (hasPermission == null || hasPermission == 0){
            throw new PermissionException("權(quán)限不足，請(qǐng)聯(lián)系管理員");
        }
        return jp.proceed();
    }

定義controller

    @PermissionCheckAnnotation(PermissionEnum.USER_CREATE)
    @PostMapping("/createUser")
    public Result<String> createUser() {
    }

后端修改權(quán)限

前端將修改完的權(quán)限發(fā)送過(guò)來(lái)，大體格式就是一個(gè)整數(shù)數(shù)組([1,2,3,4,5])，表示當(dāng)前用戶(hù)的全部權(quán)限的ID集合

權(quán)限更新的主要思路就是將該用戶(hù)的全部權(quán)限刪除，再重建

如果嫌棄太慢的話(huà)，我覺(jué)得可以取交集之類(lèi)的操作，提升效率，或者再額外定義一個(gè)字段，用來(lái)判斷當(dāng)前用戶(hù)權(quán)限的狀態(tài)（delete字段）這樣應(yīng)該會(huì)比delete insert效率高一些

不過(guò)俺是個(gè)菜鳥(niǎo)小白+懶狗，怎么簡(jiǎn)單怎么來(lái)了

刪除用戶(hù)不擁有的權(quán)限

    <delete id="deletePermission">
        delete from user_permission where user_id = #{userId}
        and permission_id not in
        <foreach item="item" collection="permissionList" open="(" close=")" separator=",">
            #{item}
        </foreach>
    </delete>

插入新權(quán)限

因?yàn)槭侨坎迦?，?quán)限可能會(huì)產(chǎn)生重復(fù)，因此我給user_id和permission_id添加唯一約束，并在插入時(shí)忽略錯(cuò)誤

    <insert id="createPermission">
        insert ignore into user_permission
        <foreach collection="permissionList" open="values" item="item" separator=",">
            (null,#{userId},#{item})
        </foreach>
    </insert>

前端

我前端不是很好，只會(huì)單純畫(huà)個(gè)界面，因此我還沒(méi)有實(shí)現(xiàn)按鈕級(jí)別的權(quán)限控制，不過(guò)大體思路是自定義指令，然后檢查是否擁有對(duì)應(yīng)的權(quán)限，如果沒(méi)有權(quán)限直接隱藏該按鈕

至于菜單級(jí)別的權(quán)限，我的做法是每次都發(fā)送一個(gè)請(qǐng)求，判斷能用多少菜單，即使被人扒出來(lái)其他界面，后端也做了權(quán)限的校驗(yàn)，數(shù)據(jù)還是拿不到

這里主要記錄下如何在前端修改權(quán)限

查詢(xún)返回的數(shù)據(jù)格式大致如下

{
    id: 15
    level: 2
    name: "操作查詢(xún)"
    parentId: 1
    remark: "操作菜單下的查詢(xún)功能"
    status: 1
}
{
    id: 1
    level: 1
    name: "操作菜單"
    parentId: null
    remark: "操作菜單"
    status: 1
}

我想要在element-Plus中的樹(shù)形控件中實(shí)現(xiàn)展示，操作功能，大致需要將上面的數(shù)據(jù)變成這樣的格式

const data: Tree[] = [
  {
    label: 'Level one 1',
    children: [
      {
        label: 'Level two 1-1',
      },
    ],
  },
]

這里通過(guò)dfs實(shí)現(xiàn)的（同層權(quán)限之間不會(huì)產(chǎn)生交集，所以應(yīng)該能用最小生成樹(shù)完成，不過(guò)俺是個(gè)懶狗，寫(xiě)了個(gè)最簡(jiǎn)單的方式）

const st = new Map();

for (let i = 0; i < res.length; i++) {
    st.set(res[i].id, 0);
}
const list = [];
for (let i = 0; i < res.length; i++) {
    if (res[i].parentId == null) {
        const children = dfs(i, res);
        list.push(children);
     }
}
tree.value = list;

function dfs(idx, res) {
    st.set(res[idx].id, 1);
    const children = []
    for (let i = 0; i < res.length; i++) {
        if (st.get(res[i].id) == 1) {
            continue;
        }
        if (res[i].parentId == res[idx].id) {
            children.push(dfs(i, res))
        }
    }
    if (children.length == 0)
        return { id: res[idx].id, label: res[idx].name }
    return { id: res[idx].id, label: res[idx].name, children }
}

然后把操作完的數(shù)據(jù)扔到elTree中

<el-tree v-loading="treeLoading"
@check="checkChange" 
style="max-width: 200px" 
ref="elTreeRef"
:data="tree"
:props="defaultProps" 
show-checkbox 
node-key="id" />

然后就是用戶(hù)的初始權(quán)限，通過(guò)點(diǎn)擊不同的用戶(hù)向后端查詢(xún)?cè)撚脩?hù)擁有的權(quán)限，el-tree有個(gè)屬性可以設(shè)置默認(rèn)勾選的復(fù)選框，但我不知道為什么點(diǎn)擊不同用戶(hù)時(shí)，樹(shù)中上一個(gè)勾選的復(fù)選框不會(huì)被取消，因此使用了el-tree的方法，當(dāng)點(diǎn)擊不同用戶(hù)時(shí)觸發(fā)，傳入的數(shù)據(jù)是一個(gè)整數(shù)數(shù)組（[1,2,3]），表示勾選的節(jié)點(diǎn)的id，需要在el-tree標(biāo)簽中提前指定node-key

elTreeRef.value.setCheckedKeys(hasPermission.value)

最后就是權(quán)限修改，大致就是用戶(hù)點(diǎn)擊不同的復(fù)選框，選擇或取消不同的權(quán)限，通過(guò)綁定@check事件，然后獲取里面的數(shù)據(jù)，這里說(shuō)一下當(dāng)點(diǎn)擊子復(fù)選框時(shí)，父復(fù)選框也會(huì)觸發(fā)一次，當(dāng)父選框下的全部子復(fù)選框都取消時(shí)，父復(fù)選框也會(huì)取消，通過(guò)下面這個(gè)方法能拿到當(dāng)前勾選的復(fù)選框，然后發(fā)送數(shù)據(jù)

    const checkChange = function (data1, data2) {
        currentPermission = [...data2.checkedKeys, ...data2.halfCheckedKeys]
    }

總結(jié)

就這樣，實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的權(quán)限校驗(yàn)?zāi)Ｐ?，雖然缺少了角色表，但大體功能上大差不差，添加上角色表后，可能還得考慮權(quán)限的遷移，權(quán)限的分配等等問(wèn)題

不過(guò)對(duì)于一個(gè)簡(jiǎn)單的系統(tǒng)來(lái)說(shuō)還是十分夠用力

還有為什么csdn還對(duì)封面圖大小設(shè)置了，把我的卡茲米都?jí)撼墒裁礃恿??????

到此這篇關(guān)于SpringBoot實(shí)現(xiàn)RBAC權(quán)限校驗(yàn)?zāi)Ｐ偷氖纠奈恼戮徒榻B到這了,更多相關(guān)SpringBoot RBAC權(quán)限校驗(yàn) 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: