簡(jiǎn)單地介紹一下業(yè)內權限系統的設計方案

權限的分類(lèi)

對于權限的控制，一般包含以下兩個(gè)方面：

        1.功能權限

        功能權限代表的就是一個(gè)用戶(hù)是否有進(jìn)行這個(gè)操作的權限，比如你有銀行卡，你登陸了網(wǎng)上銀行之后，就有取款的功能權限

        2.數據權限

數據權限代表的是一個(gè)用戶(hù)是否有對某個(gè)數據操作的權限，還是上面的例子，你有銀行卡，而且有取款功能，但是你對自己的存款具有數據權限，你只能看到自己的存款，只能取自己的錢(qián)，對于別人的存款，你是不具有數據權限的

功能權限設計

對于功能權限，一般會(huì )設計出三個(gè)實(shí)體，分別是用戶(hù)、角色、權限

一個(gè)權限代表著(zhù)一個(gè)最小單元的操作，比如查看存款，取款，轉賬

一個(gè)角色則是和一個(gè)或多個(gè)權限相關(guān)聯(lián)，比如銀行系統中的普通用戶(hù)是一個(gè)角色，普通用戶(hù)這個(gè)角色擁有查看存款、取款、轉賬這些權限

一個(gè)用戶(hù)則是和一個(gè)或多個(gè)角色相關(guān)聯(lián)，比如某個(gè)用戶(hù)賬號既是一個(gè)普通用戶(hù)，又是一個(gè)系統的后臺管理員，那么他就同時(shí)擁有作為一個(gè)普通用戶(hù)的功能權限和作為一個(gè)系統管理員的功能權限

功能權限驗證

由于功能權限是對應著(zhù)一個(gè)最小單元的操作，也就是對應著(zhù)系統后臺的一個(gè)方法，因此權限的驗證也應該是基于方法級別的。權限系統需要提供一個(gè)攔截器，負責攔截業(yè)務(wù)系統收到的所有請求，然后將以下三個(gè)信息傳遞給權限系統：

        1.當前用戶(hù)的唯一標識

        2.當前系統的唯一標識（假設權限系統是同時(shí)管理多個(gè)系統的權限控制）

        3.當前請求需要操作的功能權限的唯一標識

權限系統接收到這三個(gè)信息之后，根據當前用戶(hù)的唯一標識，獲取其對應系統下（這里假設一個(gè)用戶(hù)在多個(gè)系統下也是可以登陸的，也就是多個(gè)系統共用一套用戶(hù)體系）的所有角色，然后根據這些角色獲取到這個(gè)用戶(hù)在這個(gè)系統下的所有功能權限的列表，最后再判斷當前請求的功能權限是否在這個(gè)用戶(hù)的權限列表之中，如果在，則表示該用戶(hù)具有這個(gè)功能權限，不在的話(huà)就表示當前用戶(hù)沒(méi)有這個(gè)權限

數據權限設計

對于功能權限，上述的方案基本上已經(jīng)是一個(gè)比較統一的標準了，可是對于數據權限來(lái)說(shuō)，業(yè)內還沒(méi)有一個(gè)非常完美的方案，因為數據權限的控制和系統本身的業(yè)務(wù)是緊密相連的，比如說(shuō)銀行系統、圖書(shū)管理系統、SNS網(wǎng)站，這些系統對數據權限的控制、要求肯定是不一樣的，而權限系統是獨立于業(yè)務(wù)系統之外的，權限系統本身不可能了解到業(yè)務(wù)系統的業(yè)務(wù)，也不應該去了解業(yè)務(wù)系統的業(yè)務(wù)，因此對于數據權限的控制，權限系統是無(wú)法提供一套完美的解決方案的，一般的做法是，權限系統提供一個(gè)數據權限控制的標準，然后所有的業(yè)務(wù)系統按照這個(gè)標準去實(shí)現自身數據權限控制的目標。

        一般來(lái)說(shuō)，一條數據會(huì )有兩個(gè)歸屬：

        1.owner，表示創(chuàng )建這個(gè)數據的用戶(hù)，比如說(shuō)我在論壇的游戲頻道發(fā)布一個(gè)帖子，那么我就是我這個(gè)帖子的創(chuàng )建者，這個(gè)帖子應該有一個(gè)ownerId的字段來(lái)標識這個(gè)帖子是我創(chuàng )建的，因此這個(gè)帖子只有我能夠修改

        2.organization，表示這個(gè)數據所屬的組織（注意，這里的組織和平時(shí)我們說(shuō)的組織的概念，有時(shí)候會(huì )不一樣），比如上面的例子，這個(gè)帖子是在游戲頻道發(fā)布的，那么這個(gè)帖子就應該是屬于游戲頻道這個(gè)組織

        基于以上兩點(diǎn)，我們可以對需要做數據權限驗證的數據添加 ownerId 和 organizationId 這兩個(gè)字段，并實(shí)現一個(gè)數據權限驗證的接口

        對于一個(gè)用戶(hù)來(lái)說(shuō)，他自己本身的唯一標識就可以看做是一個(gè) ownerId，而用戶(hù)也是有所屬的，比如游戲頻道的版主，他就是屬于游戲頻道這個(gè)組織的

數據權限驗證

數據權限驗證是基于功能權限驗證的基礎上的，當判斷出當前用戶(hù)有用功能權限，需要進(jìn)行數據權限控制的時(shí)候，會(huì )有兩種情況：

        1.當前用戶(hù)只是進(jìn)行查詢(xún)的操作，則業(yè)務(wù)系統會(huì )將當前用戶(hù)需要執行的SQL傳給權限系統，權限系統會(huì )根據當前用戶(hù)的唯一標識和他所屬的組織對SQL進(jìn)行一個(gè)加工——在SQL的尾部添加 ownerId 和 organizationId 的判斷條件，使得當前用戶(hù)能查詢(xún)到的數據是他有權限看到的

        2.當前用戶(hù)在進(jìn)行修改、刪除操作時(shí)，則權限系統會(huì )根據當前用戶(hù)的 ownerId 和 organizationId 來(lái)判斷他是否有權限去進(jìn)行操作

上述說(shuō)到的例子里面，其實(shí)還涉及到一個(gè)數據權限控制策略的問(wèn)題，一般會(huì )有下面幾種情況：

        1.數據只有所屬者可以進(jìn)行操作，也就是只有ownerId匹配的時(shí)候，才能進(jìn)行操作

        2.數據在統一個(gè)組織內是共享的，也就是當期那用戶(hù)的 organizationId 和數據所屬的 organizationId 匹配，就能進(jìn)行操作

        3.組織之間有樹(shù)型的層級關(guān)系，比如一個(gè)論壇分為游戲頻道、小說(shuō)頻道，那么整個(gè)系統的管理員所屬的組織是整個(gè)論壇，游戲頻道版主的組織是游戲頻道，那么系統管理員擁有其下屬組織對應的數據的所有權限

在現實(shí)的情況中，數據權限控制的策略可能還有更多的情況，我們可以針對不同的情況去做更進(jìn)一步的抽象

總的來(lái)說(shuō)，一個(gè)權限系統需要做的事情大概就是這些，主要爭議的地方是在數據權限的控制方面，更多的時(shí)候，我們會(huì )讓各自的業(yè)務(wù)系統自己去完成數據權限的控制，而權限系統只做功能權限的控制，畢竟實(shí)現上面的那套數據權限的標準，在某些場(chǎng)景下是得不償失的