說到許可權很多人都會想到rbac，acl等等，這些方案都是十分成熟的許可權管理方案，最早寫php用yii2框架的時候，就自帶了rbac許可權管理，也對rbac比較熟悉，但今天想說的不僅僅侷限於路由許可權。
關於rbac許可權管理gg可以出一堆文章，基於角色的訪問控制，把一堆路由分配給乙個角色，然後把一堆角色分配給專案中的某個人，此人即擁有這些路由的訪問許可權。
這裡只對rbac做出簡單的說明，此處不多說。
現在的矛盾來了，如果兩個人people_a和people_b分別屬於兩個專案組team_a, team_b，同時這兩個專案組分別擁有一條資料data_a, data_b，此資料有如下兩條路由：
people_a和people_b都擁有上述兩個路由的許可權，那麼怎麼區分二者只能操作各自組的資料data_a和data_b？這裡答案還是挺簡單的，人與資料同時繫結了專案組，只需要判斷人操作的資料是否同時屬於乙個專案組即可！！！
問題是否就這麼簡單呢？
再進一步的需求： people_a需要擁有team_b的data_b資料的上述兩條資料許可權，又該如何解決？
這個問題也比較簡單，可以修改我們的業務邏輯。每個人可以屬於多個組，即將people_a加入team_b組，那麼只需要在做data_b的許可權判斷是判斷people_a所在的所有組，只要乙個組與data_b是在乙個組即可！！！
好開心呀，上述問題都解決了，是否就完了呢？
需求又來了，people_a只能擁有team_b的data_b資料的查詢資料詳情路由(get /project/data)的許可權，即people_a只能檢視data_b資料，不能修改。 這個需求如何搞？
好像現有的解決方案沒法整呀！
下面進入正題，新鮮出爐的一套許可權解決方案，也是我們專案經過多次許可權的折騰最終總結出來的。
說了上述幾點，可能由於文字功底不足，完全聽不懂，舉個形象的栗子：signkey就是乙個qq群，建立此signkey的就是群主，群主可以將資料上傳到該群中，然後再拉一些人到此群中，那麼這些人就能夠對這些資料進行操作。同時給每個人分配的路由不一樣，那麼每個人對資料的操作許可權也不一樣，可以控制到部分人能夠訪問和修改資料，部分人只能訪問資料而不能修改資料。
talk is cheap, show me your code!
下面具體從資料結構層面分析，如下**全部是golang編寫，下述資料結構適用於mongodb的儲存。
type routeinfo struct
type verifydata struct
get
-->
1post
-->
2put
-->
4delete
-->
8
type roleinfo struct
type address struct
type userinfo struct
type signinfo struct
對於signkey解決資料許可權的栗子：
整個許可權的設計思路和資料結構即說明結束了，下面需要解決另乙個問題。
現在許多路由都是動態路由，什麼是動態路由：
此時的問題就是如何使用者訪問請求能夠成功匹配上專案定義的路由？解決方案有兩個：
最後簡單給出，我們實現方案簡單的許可權判斷流程圖：圖上的說明應該能看懂，這裡僅僅是我們的許可權判斷流程，需要採用者，可以結合上述思路進行擴充套件。
此許可權的設計方案是我們經過兩年來幾次失敗的設計後最新得出來的方案，經過初步的檢驗能夠解決開篇說的那些矛盾和我們專案的一些許可權矛盾，希望對各位讀者有用。
RABC許可權管理
rabc 許可權管理 一 許可權管理的目的 1 統一精細化 標準化許可權管理。2 業務應用資料許可權多樣性，不同的應用資料管控的方式要求不同 同乙個應用不同的場景和功能對許可權的控制不同，需要建設通用性的許可權模型 3 許可權模型的建模需要支援多級管控。4 許可權自管控 二 rabc 許可權管理 1...
RABC許可權管理學習
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
django後台許可權管理（基於角色控制管理）
元件原始碼 使用自定義rbac許可權元件 1.拷貝rbac元件 2.清空migration目錄 3.在setting註冊rbac python rbac django 2.0以上 4.資料庫遷移錄入資訊 5.建立超級管理，新增許可權資訊 元件admin.py已經定製化 6.使用者登入後做許可權和選單...