限管理實(shí)戰(zhàn)：模型設(shè)計(jì)、校驗(yàn)實(shí)現(xiàn)與性能優(yōu)化)
做后端的人都繞不過(guò)權(quán)限管理這關(guān)。早幾年我在某公司負(fù)責(zé)一個(gè)后臺(tái)管理系統(tǒng)業(yè)務(wù)功能加了一堆用戶(hù)角色越來(lái)越亂每次梳理權(quán)限都在加班補(bǔ)窟窿。那段時(shí)間我光是整理權(quán)限清單就要花小半天更別提上線(xiàn)之后各種“這個(gè)功能明明能用換個(gè)賬號(hào)就報(bào)403”的反饋。后來(lái)花了兩個(gè)晚上把整個(gè)項(xiàng)目的權(quán)限模塊推倒重來(lái)用RBAC模型重新建模才徹底把這塊理順了。如果你也在用Django做后臺(tái)系統(tǒng)或者正準(zhǔn)備給項(xiàng)目加權(quán)限控制這篇就把我的方案、踩過(guò)的坑、以及排查思路完整講一遍。Django自帶的auth應(yīng)用里其實(shí)已經(jīng)有Group用戶(hù)組和Permission權(quán)限兩張表也能做到基于角色的粗粒度控制但真正落到業(yè)務(wù)里你會(huì)發(fā)現(xiàn)原生的東西離“夠用”還差得遠(yuǎn)。比如“菜單級(jí)權(quán)限”“按鈕級(jí)權(quán)限”“不同部門(mén)的相同角色擁有不同數(shù)據(jù)范圍”這些需求光靠Django原生那套很難優(yōu)雅實(shí)現(xiàn)。所以我基于RBAC的核心思想在Django上做了一套更完整的權(quán)限體系包含用戶(hù)、角色、權(quán)限、菜單四個(gè)維度下面從設(shè)計(jì)思路開(kāi)始逐個(gè)拆解。1. RBAC權(quán)限模型的設(shè)計(jì)思路1.1 RBAC到底解決了什么問(wèn)題在RBACRole-Based Access Control基于角色的訪(fǎng)問(wèn)控制之前很多小項(xiàng)目用的是最原始的方式在用戶(hù)表里直接存“是不是管理員”“能不能導(dǎo)出”“能不能刪數(shù)據(jù)”之類(lèi)的布爾字段。用戶(hù)少的時(shí)候沒(méi)什么用戶(hù)一多、功能一多就亂了——今天A要加一個(gè)導(dǎo)出權(quán)限明天B也要加后天發(fā)現(xiàn)C不該有但代碼里已經(jīng)寫(xiě)死了判斷邏輯只能頻繁改代碼、改數(shù)據(jù)庫(kù)最后誰(shuí)都不敢動(dòng)權(quán)限相關(guān)的東西。RBAC的核心思路是引入“角色”這個(gè)中間層。用戶(hù)不直接綁定權(quán)限而是綁定角色角色再擁有權(quán)限。這樣一來(lái)權(quán)限的分配變成角色與權(quán)限的配置而不再需要頻繁修改用戶(hù)代碼或表結(jié)構(gòu)。類(lèi)比一下一家公司的門(mén)禁卡系統(tǒng)員工不是直接擁有“進(jìn)財(cái)務(wù)室”的權(quán)利而是因?yàn)椤柏?cái)務(wù)部員工”這個(gè)崗位角色天然就被授權(quán)進(jìn)入了財(cái)務(wù)室。換崗的時(shí)候只需要換角色不需要挨個(gè)改門(mén)禁記錄。加上“角色”這層抽象之后權(quán)限管理從“點(diǎn)對(duì)點(diǎn)”變成了“面到面”數(shù)據(jù)集小、邏輯清晰、可追溯。這就是RBAC能成為主流權(quán)限方案的根本原因。1.2 為什么最終選了RBAC而不是ACL或ABAC做權(quán)限選型的時(shí)候市面上主要有三種模型ACLAccess Control List、RBACRole-Based Access Control、ABACAttribute-Based Access Control。ACL是最樸素的思路——直接把某個(gè)用戶(hù)和某種操作權(quán)限掛上鉤。適合小型工單系統(tǒng)、個(gè)人博客后臺(tái)但一旦用戶(hù)量上百、功能上百ACL表的膨脹速度非常驚人而且無(wú)法自然表達(dá)“一類(lèi)人”的共性權(quán)限。ABAC則更靈活用屬性規(guī)則來(lái)判斷比如說(shuō)“銷(xiāo)售部門(mén)的員工只能看本部門(mén)客戶(hù)的工單”但要維護(hù)規(guī)則引擎、表達(dá)式解析復(fù)雜度直接上一個(gè)臺(tái)階中小型項(xiàng)目一般是hold不住的。所以在絕大多數(shù)管理后臺(tái)、中后臺(tái)系統(tǒng)的場(chǎng)景里RBAC是性?xún)r(jià)比最高的方案。它管住了“誰(shuí)能做什么”又不像ABAC那樣引入巨大的規(guī)則復(fù)雜度。而如果后面又出現(xiàn)“不同角色只能看不同部門(mén)數(shù)據(jù)”這種行級(jí)數(shù)據(jù)權(quán)限需求也完全可以在RBAC的基礎(chǔ)上增加一個(gè)數(shù)據(jù)范圍字段來(lái)配合實(shí)現(xiàn)不需要推翻整體設(shè)計(jì)。這也是我在實(shí)操中最終選擇RBAC并保留擴(kuò)展空間的原因。1.3 Django自帶的auth權(quán)限體系夠不夠用凡是開(kāi)過(guò)Django項(xiàng)目的人都知道django.contrib.auth里已經(jīng)提供了User、Group、Permission還自帶has_perm()方法和permission_required裝飾器。那為什么我還要自己再擼一套R(shí)BAC因?yàn)樵脑O(shè)計(jì)目標(biāo)是“給Django管理后臺(tái)admin提供權(quán)限控制”而不是直接給業(yè)務(wù)系統(tǒng)做權(quán)限中臺(tái)。它的問(wèn)題主要集中在幾點(diǎn)第一權(quán)限粒度是按模型來(lái)的一個(gè)Permission對(duì)應(yīng)“添加/修改/刪除/查看某個(gè)模型”但你做業(yè)務(wù)系統(tǒng)時(shí)會(huì)有“導(dǎo)出報(bào)表”“審批工單”“分配任務(wù)”這類(lèi)跟模型CRUD不對(duì)應(yīng)的操作權(quán)限原生比較難表達(dá)。第二菜單和接口權(quán)限沒(méi)有天然建模。你做的是帶側(cè)邊欄的后臺(tái)側(cè)邊欄菜單誰(shuí)可見(jiàn)誰(shuí)不可見(jiàn)原生完全不管需要自己去查詢(xún)、渲染。第三Group雖然可以作為角色表用但它只能關(guān)聯(lián)權(quán)限不能掛級(jí)聯(lián)的數(shù)據(jù)范圍、角色層級(jí)、排序等擴(kuò)展字段使用起來(lái)限制很大。所以實(shí)操中我保留了Django原生的Permission來(lái)承接原子操作權(quán)限再用自定義的Role、Menu等模型來(lái)承載業(yè)務(wù)權(quán)限結(jié)構(gòu)。原生框架的理念值得沿用但必須做擴(kuò)展才能真正支撐起一個(gè)靈活的后臺(tái)權(quán)限系統(tǒng)。2. 數(shù)據(jù)模型與表結(jié)構(gòu)設(shè)計(jì)2.1 五張核心表的職責(zé)劃分在給后臺(tái)系統(tǒng)設(shè)計(jì)RBAC表結(jié)構(gòu)時(shí)我最終拆出了五張核心表外加兩張關(guān)聯(lián)中間表。五張核心表的職責(zé)非常清晰User用戶(hù)表直接用Django的AbstractUser擴(kuò)展增加外鍵關(guān)聯(lián)到角色也可保留原生的多對(duì)多關(guān)系。Role角色表存儲(chǔ)角色名稱(chēng)、角色標(biāo)識(shí)符、排序、狀態(tài)、數(shù)據(jù)范圍等。Permission權(quán)限表存儲(chǔ)權(quán)限編碼、名稱(chēng)可以直接沿用Django自帶的Permission也可以自定義一張權(quán)限表看項(xiàng)目規(guī)模。Menu菜單表存儲(chǔ)系統(tǒng)菜單、按鈕包括菜單類(lèi)型目錄/菜單/按鈕、路由地址、權(quán)限標(biāo)識(shí)等。MenuRole、RoleUser關(guān)聯(lián)表由于角色和菜單、角色和用戶(hù)都是多對(duì)多關(guān)系所以需要中間表來(lái)維護(hù)。這里有個(gè)關(guān)鍵取舍我是直接用Django的Permission還是另建一張Permission表如果你的項(xiàng)目是在Django Admin體系內(nèi)做管理直接復(fù)用即可但如果你要寫(xiě)一個(gè)獨(dú)立的后臺(tái)管理系統(tǒng)我更建議自定義Permission表或菜單表自帶權(quán)限標(biāo)識(shí)因?yàn)槟愫笃跁?huì)有大量“查詢(xún)權(quán)限是否存在”“校驗(yàn)?zāi)硞€(gè)請(qǐng)求URL是否匹配某個(gè)權(quán)限標(biāo)識(shí)”的場(chǎng)景自己的表更靈活可控不用跟Django的ContentType混在一起。下面給出我實(shí)際使用的一套模型定義。2.2 核心模型代碼實(shí)例先擴(kuò)展用戶(hù)模型。用AbstractUser加一個(gè)roles多對(duì)多字段兼容Django原本的groups和user_permissions。from django.contrib.auth.models import AbstractUser, Permission from django.db import models class User(AbstractUser): 擴(kuò)展用戶(hù)表增加與角色的多對(duì)多關(guān)系 roles models.ManyToManyField( Role, throughUserRole, related_nameusers, blankTrue, verbose_name角色列表 ) # 如果業(yè)務(wù)需要可以增加部門(mén)、崗位等字段 department models.CharField(max_length64, blankTrue, verbose_name部門(mén)) class Meta(AbstractUser.Meta): verbose_name 用戶(hù) verbose_name_plural verbose_name然后是Role模型給角色增加數(shù)據(jù)范圍和狀態(tài)等擴(kuò)展字段。class Role(models.Model): 角色表 DATA_SCOPE_CHOICES [ (1, 全部數(shù)據(jù)), (2, 本部門(mén)及以下), (3, 僅本部門(mén)), (4, 僅本人), ] name models.CharField(max_length64, uniqueTrue, verbose_name角色名稱(chēng)) code models.CharField(max_length64, uniqueTrue, verbose_name角色標(biāo)識(shí)) data_scope models.IntegerField(choicesDATA_SCOPE_CHOICES, default3, verbose_name數(shù)據(jù)范圍) status models.BooleanField(defaultTrue, verbose_name狀態(tài)) sort models.IntegerField(default0, verbose_name排序) permissions models.ManyToManyField(Permission, blankTrue, verbose_name權(quán)限列表) desc models.CharField(max_length256, blankTrue, verbose_name角色描述) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.name class Meta: db_table system_role verbose_name 角色 verbose_name_plural verbose_name這里要注意permissions字段與Django原生的Permission建立多對(duì)多關(guān)系這樣一方面可以兼容has_perm相關(guān)的邏輯另一方面也給權(quán)限的批量管理留好了口子。接下來(lái)是Menu表。它承載了兩個(gè)功能一是后臺(tái)側(cè)邊欄菜單的渲染二是按鈕級(jí)權(quán)限的判斷。因?yàn)楹芏鄼?quán)限校驗(yàn)最終都落到“某個(gè)按鈕標(biāo)識(shí)是否在用戶(hù)的權(quán)限集合里”所以菜單表需要一個(gè)唯一的perms字段來(lái)標(biāo)識(shí)。class Menu(models.Model): 菜單與按鈕權(quán)限表 MENU_TYPE_CHOICES [ (1, 目錄), (2, 菜單), (3, 按鈕), ] parent models.ForeignKey( self, on_deletemodels.CASCADE, nullTrue, blankTrue, related_namechildren, verbose_name父級(jí)菜單 ) name models.CharField(max_length64, verbose_name菜單名稱(chēng)) path models.CharField(max_length255, blankTrue, verbose_name路由地址) component models.CharField(max_length255, blankTrue, verbose_name前端組件路徑) perms models.CharField(max_length255, blankTrue, verbose_name權(quán)限標(biāo)識(shí)) type models.IntegerField(choicesMENU_TYPE_CHOICES, default2, verbose_name菜單類(lèi)型) icon models.CharField(max_length128, blankTrue, verbose_name圖標(biāo)) sort models.IntegerField(default0, verbose_name排序) visible models.BooleanField(defaultTrue, verbose_name是否顯示) status models.BooleanField(defaultTrue, verbose_name狀態(tài)) roles models.ManyToManyField(Role, throughMenuRole, related_namemenus, blankTrue, verbose_name角色列表) class Meta: db_table system_menu verbose_name 菜單 verbose_name_plural verbose_name def __str__(self): return self.name最后是兩個(gè)中間表。雖然Django會(huì)自動(dòng)生成但我需要給中間表增加自定義字段所以顯式寫(xiě)出來(lái)。class UserRole(models.Model): 用戶(hù)-角色中間表 user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameuser_roles) role models.ForeignKey(Role, on_deletemodels.CASCADE, related_nameuser_roles) class MenuRole(models.Model): 角色-菜單中間表 role models.ForeignKey(Role, on_deletemodels.CASCADE, related_namemenu_roles) menu models.ForeignKey(Menu, on_deletemodels.CASCADE, related_namemenu_roles) class Meta: unique_together (role, menu)從實(shí)操角度看這樣的模型設(shè)計(jì)已經(jīng)能覆蓋95%以上后臺(tái)系統(tǒng)的權(quán)限需求。如果還要再升級(jí)可以將User和Role改成多對(duì)多扁平結(jié)構(gòu)允許一個(gè)用戶(hù)擁有多個(gè)角色數(shù)據(jù)權(quán)限則可以借助data_scope字段在查詢(xún)中動(dòng)態(tài)拼接SQL或ORM過(guò)濾條件。2.3 表關(guān)系與預(yù)置數(shù)據(jù)規(guī)劃表關(guān)系上整體是典型的“星型結(jié)構(gòu)”用戶(hù)表在中心左邊連著角色右邊連著權(quán)限菜單表作為前端渲染和權(quán)限標(biāo)識(shí)的錨點(diǎn)和角色建立關(guān)聯(lián)。為了讓查詢(xún)性能更好我在Role里直接持有permissions多對(duì)多關(guān)系在Menu里直接持有roles多對(duì)多關(guān)系這樣查詢(xún)用戶(hù)時(shí)可以先拿到角色再由角色快速關(guān)聯(lián)到菜單和權(quán)限。初始化數(shù)據(jù)時(shí)建議做一個(gè)基礎(chǔ)數(shù)據(jù)腳本用Django的management command來(lái)跑不要手動(dòng)往庫(kù)里插否則環(huán)境差異很容易造成數(shù)據(jù)不一致。一個(gè)典型的初始化流程是創(chuàng)建超級(jí)管理員角色并綁定所有權(quán)限標(biāo)識(shí)。創(chuàng)建通用角色如普通用戶(hù)、運(yùn)維只讀角色綁定對(duì)應(yīng)的菜單和權(quán)限。創(chuàng)建系統(tǒng)的菜單結(jié)構(gòu)目錄、菜單、按鈕三個(gè)層級(jí)分開(kāi)錄入。把默認(rèn)的超級(jí)管理員的用戶(hù)ID與角色綁定。我自己實(shí)際跑起來(lái)的時(shí)候發(fā)現(xiàn)最費(fèi)時(shí)間的不是寫(xiě)模型而是整理菜單和權(quán)限標(biāo)識(shí)的清單。這個(gè)清單直接決定后續(xù)權(quán)限管理的易用性。權(quán)限標(biāo)識(shí)的命名我建議統(tǒng)一用冒號(hào)分層例如system:user:add、system:user:edit、system:user:delete。這樣正則匹配容易前端按鈕和后端接口校驗(yàn)也好統(tǒng)一對(duì)。3. 實(shí)操落地權(quán)限校驗(yàn)完整實(shí)現(xiàn)3.1 項(xiàng)目初始化與配置第一步自然是搭一個(gè)可運(yùn)行的Django項(xiàng)目。我習(xí)慣先用獨(dú)立的目錄把項(xiàng)目建好再逐步合入權(quán)限模塊?；A(chǔ)配置里需要把自定義用戶(hù)模型設(shè)置好在settings.py里加AUTH_USER_MODEL然后注冊(cè)到INSTALLED_APPS。# settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, # 如果走API型后臺(tái)建議集成DRF system, # 權(quán)限所在的業(yè)務(wù)模塊 ] AUTH_USER_MODEL system.User我用Django REST Framework的原因是當(dāng)前后臺(tái)管理基本都是前后端分離的后端只提供JSON接口權(quán)限校驗(yàn)放在視圖層和中間件層。如果不打算前后端分離也可以忽略DRF直接用View和模板渲染菜單。隨后執(zhí)行遷移命令確認(rèn)模型建表沒(méi)問(wèn)題。python manage.py makemigrations python manage.py migrate這個(gè)時(shí)候有個(gè)非常容易踩的坑如果你是在已有項(xiàng)目上引入AUTH_USER_MODEL數(shù)據(jù)庫(kù)里可能已經(jīng)有了其他表的外鍵關(guān)聯(lián)到原生的auth.User遷移會(huì)直接報(bào)錯(cuò)。解決方法是先確保被關(guān)聯(lián)的表比如日志表、工單表要么用settings.AUTH_USER_MODEL做外鍵要么在引入之前處理好懸空外鍵的問(wèn)題。3.2 權(quán)限校驗(yàn)裝飾器與中間件有了模型之后最核心的部分就是把“權(quán)限標(biāo)識(shí)”和“接口請(qǐng)求”關(guān)聯(lián)起來(lái)。我封了一個(gè)裝飾器permission_check用于視圖函數(shù)或DRF視圖類(lèi)。from django.http import JsonResponse from functools import wraps def permission_check(perm_code): 簡(jiǎn)單的權(quán)限校驗(yàn)裝飾器支持DRF視圖 def decorator(view_func): wraps(view_func) def wrapped_view(request, *args, **kwargs): if not request.user.is_authenticated: return JsonResponse({code: 401, msg: 未登錄}, status401) if request.user.is_superuser: return view_func(request, *args, **kwargs) # 從request中取出用戶(hù)擁有的權(quán)限集合 perm_set request.user.get_all_permissions() if perm_code not in perm_set: return JsonResponse({code: 403, msg: 無(wú)權(quán)限訪(fǎng)問(wèn)}, status403) return view_func(request, *args, **kwargs) return wrapped_view return decorator permission_check(system:user:add) def add_user(request): # 新增用戶(hù)邏輯 pass這里的關(guān)鍵點(diǎn)在于request.user.get_all_permissions()為了讓它每次都返回最新權(quán)限我在User模型上自定義了一個(gè)方法。這個(gè)方法的核心邏輯是從當(dāng)前用戶(hù)關(guān)聯(lián)的角色找到這些角色綁定的權(quán)限收集所有權(quán)限編碼。from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): roles models.ManyToManyField(Role, throughUserRole, related_nameusers, blankTrue) def get_all_permissions(self): if self.is_superuser: # 超級(jí)管理員直接返回一個(gè)始終包含通過(guò)的標(biāo)記 return {*,} # 通過(guò)角色收集權(quán)限編碼 perms set() role_ids self.roles.filter(statusTrue).values_list(id, flatTrue) for role_id in role_ids: # 從Role關(guān)聯(lián)到Permission permissions Role.objects.get(pkrole_id).permissions.all() for p in permissions: perms.add(p.codename) # 如果還涉及菜單表權(quán)限標(biāo)識(shí) menu_perm Menu.objects.filter(roles__id__inrole_ids, perms__isnullFalse).values_list(perms, flatTrue) perms.update(menu_perm) return perms這里有一個(gè)容易混淆的點(diǎn)Django原生Permission自帶codename這個(gè)codename是像add_userchange_user這樣的短名稱(chēng)但為了方便統(tǒng)一控制我更建議直接把權(quán)限標(biāo)識(shí)寫(xiě)入codename或新建一個(gè)字段比如system:user:add。實(shí)際項(xiàng)目中為了讓菜單權(quán)限和后端權(quán)限共用一個(gè)權(quán)限集合下面這段邏輯是主流做法。不過(guò)要注意get_all_permissions這個(gè)方法是DjangoBaseUser里就存在的鉤子我在覆寫(xiě)時(shí)保留一致的返回類(lèi)型后面很多內(nèi)置功能都不會(huì)出問(wèn)題。如果不想在每一個(gè)視圖函數(shù)上加裝飾器也可以在中間件層做統(tǒng)一攔截。以下是我常用的一個(gè)輕量中間件它把“白名單 登錄態(tài)”自動(dòng)處理了。class RbacMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): # 對(duì)不需要權(quán)限校驗(yàn)的路由放行 path request.path allow_list [ /api/login/, /api/captcha/, /static/, ] if any(path.startswith(prefix) for prefix in allow_list): return self.get_response(request) if not request.user.is_authenticated: return JsonResponse({code: 401, msg: 未登錄}, status401) # 判斷當(dāng)前請(qǐng)求的URL是否需要“資源權(quán)限”校驗(yàn) # 通過(guò)一個(gè)服務(wù)函數(shù)獲取 URL - 權(quán)限標(biāo)識(shí) 的映射關(guān)系 perm_code matcher.get_permission_by_path(path) if perm_code and not request.user.is_superuser: if perm_code not in request.user.get_all_permissions(): return JsonResponse({code: 403, msg: 無(wú)權(quán)限訪(fǎng)問(wèn)}, status403) return self.get_response(request)用中間件的好處是接口不用逐個(gè)加裝飾器新增接口只要在路由配置的時(shí)候做好權(quán)限標(biāo)識(shí)和路徑的映射就行。但它也有一個(gè)劣勢(shì)——每個(gè)請(qǐng)求都會(huì)跑一遍權(quán)限檢查對(duì)性能有一定影響所以通常會(huì)和緩存方案配合使用。后面第4章我會(huì)專(zhuān)門(mén)講性能優(yōu)化。3.3 前端菜單與按鈕級(jí)權(quán)限控制做后臺(tái)管理系統(tǒng)前端核心訴求就兩個(gè)菜單按角色動(dòng)態(tài)渲染按鈕按權(quán)限動(dòng)態(tài)顯示。前端拿到當(dāng)前用戶(hù)后調(diào)用一個(gè)獲取用戶(hù)信息的接口接口返回該用戶(hù)可見(jiàn)的菜單樹(shù)和權(quán)限標(biāo)識(shí)集合。在Django視圖里獲取菜單樹(shù)的邏輯大概是這樣的def get_user_menu_tree(request): user request.user if user.is_superuser: menus Menu.objects.filter(statusTrue, type__in[1, 2]).order_by(sort) else: role_ids user.roles.filter(statusTrue).values_list(id, flatTrue) menus Menu.objects.filter(roles__id__inrole_ids, statusTrue, type__in[1, 2]).order_by(sort) tree build_menu_tree(menus) return JsonResponse({code: 200, data: tree}) def build_menu_tree(menus): 將扁平的菜單列表轉(zhuǎn)換為樹(shù)形結(jié)構(gòu) menu_list list(menus.values(id, parent_id, name, path, component, icon, sort, type)) tree [] # 轉(zhuǎn)化為dict便于快速查找 menu_map {} for item in menu_list: parent_id item.pop(parent_id) item[children] [] menu_map[item[id]] item # 組裝樹(shù) for item in menu_list: item.pop(parent_id, None) return menu_list上面的代碼為了簡(jiǎn)化示例我忽略了遞歸組樹(shù)的過(guò)程實(shí)際需要遞歸根據(jù)parent_id掛到對(duì)應(yīng)的children里。前端拿到這棵菜單樹(shù)之后直接遍歷渲染側(cè)邊欄即可。按鈕級(jí)權(quán)限同理接口返回一個(gè)扁平的權(quán)限標(biāo)識(shí)列表前端在按鈕上判斷const hasPerm (perm) { return store.state.permissions.includes(perm); }這樣就能實(shí)現(xiàn)“角色變了按鈕自動(dòng)隱藏”的效果。需要注意的是前端權(quán)限控制只是體驗(yàn)優(yōu)化真正的安全防線(xiàn)永遠(yuǎn)在后端。接口和數(shù)據(jù)的權(quán)限校驗(yàn)不能因?yàn)榍岸穗[藏了入口就省略一定要在視圖層再校驗(yàn)一次防止有人直接請(qǐng)求接口地址。4. 性能優(yōu)化與緩存方案4.1 權(quán)限查詢(xún)的N1問(wèn)題RBAC模型在實(shí)現(xiàn)之后最容易暴露的問(wèn)題就是查詢(xún)性能。原因很簡(jiǎn)單用戶(hù) - 角色 - 權(quán)限 - 菜單是多層關(guān)聯(lián)如果不做優(yōu)化一次權(quán)限查詢(xún)會(huì)實(shí)時(shí)發(fā)起大量SQL。舉個(gè)例子如果用戶(hù)有3個(gè)角色每個(gè)角色有20個(gè)權(quán)限標(biāo)識(shí)那么獲取用戶(hù)全部權(quán)限時(shí)如果用遍歷角色的方式逐個(gè)查詢(xún)權(quán)限SQL次數(shù)就是“1次查角色 N次查權(quán)限”。在用戶(hù)登錄、用戶(hù)訪(fǎng)問(wèn)接口、獲取菜單樹(shù)這些關(guān)鍵節(jié)點(diǎn)都會(huì)被放大多倍。解決方案有兩個(gè)層面。第一個(gè)層面是使用prefetch_related預(yù)取關(guān)聯(lián)數(shù)據(jù)在查詢(xún)角色列表時(shí)就把每個(gè)角色的權(quán)限集合一次性取出來(lái)例如roles Role.objects.filter(statusTrue).prefetch_related(permissions)第二個(gè)層面更徹底——把權(quán)限集合做緩存不用每次請(qǐng)求都去數(shù)據(jù)庫(kù)里查。4.2 緩存策略與Redis集成考慮到權(quán)限數(shù)據(jù)的特點(diǎn)是“讀多寫(xiě)少”非常適合用緩存。我在項(xiàng)目里把用戶(hù)權(quán)限集合、菜單樹(shù)都放到了Redis里緩存前綴按用戶(hù)ID區(qū)分例如rbac:perms:user:{user_id}緩存時(shí)間設(shè)為30分鐘。集成Redis之后get_all_permissions()的改造邏輯是這樣的from django.core.cache import cache def get_all_permissions(self): cache_key frbac:perms:user:{self.id} perms cache.get(cache_key) if perms is not None: return perms # 未命中則從數(shù)據(jù)庫(kù)查詢(xún) if self.is_superuser: perms {*,} else: perms set() role_list self.roles.filter(statusTrue).prefetch_related(permissions) for role in role_list: for p in role.permissions.all(): perms.add(p.codename) # 補(bǔ)充菜單權(quán)限標(biāo)識(shí) menu_perms Menu.objects.filter( roles__id__inself.roles.filter(statusTrue), perms__isnullFalse ).values_list(perms, flatTrue) perms.update(menu_perms) # 寫(xiě)入緩存 cache.set(cache_key, perms, timeout1800) return perms這里有個(gè)細(xì)節(jié)perms是無(wú)序集合在緩存時(shí)要注意cache.set能否接受set類(lèi)型。大部分Redis緩存后端會(huì)自動(dòng)把set序列化成list取回來(lái)就變成list了所以最好在寫(xiě)入前統(tǒng)一list(perms)讀取時(shí)再轉(zhuǎn)成集合避免類(lèi)型不一致導(dǎo)致后續(xù)in判斷出錯(cuò)。另外我強(qiáng)烈建議把緩存的鍵設(shè)計(jì)成可控制的版本號(hào)比如rbac:perms:user:{user_id}:v2。這樣當(dāng)權(quán)限邏輯升級(jí)時(shí)只需要改版本號(hào)讓舊緩存自然失效避免老用戶(hù)因?yàn)榕f緩存一直看到舊的權(quán)限數(shù)據(jù)。4.3 權(quán)限變更即時(shí)生效緩存能提升性能但也帶來(lái)一個(gè)常見(jiàn)問(wèn)題管理員修改了角色權(quán)限用戶(hù)的緩存卻沒(méi)有及時(shí)刷新導(dǎo)致新權(quán)限遲遲不生效。解決辦法是在權(quán)限變更的業(yè)務(wù)邏輯里主動(dòng)清除對(duì)應(yīng)用戶(hù)的緩存。實(shí)際處理時(shí)我封裝了一個(gè)服務(wù)類(lèi)專(zhuān)門(mén)負(fù)責(zé)角色權(quán)限的修改與緩存清理class RbacService: staticmethod def assign_permissions_to_role(role, perm_codes): 給角色分配權(quán)限 # 處理權(quán)限編碼的更新 role.permissions.clear() ... # 清理所有擁有該角色的用戶(hù)的緩存 user_ids role.users.values_list(user_id, flatTrue) for user_id in user_ids: cache_key frbac:perms:user:{user_id} cache.delete(cache_key)有同學(xué)可能會(huì)問(wèn)如果沒(méi)有Redis緩存而是本地內(nèi)存緩存這個(gè)失效怎么處理我建議不要把本地緩存作為核心方案因?yàn)槎噙M(jìn)程部署下本地緩存無(wú)法聯(lián)動(dòng)失效最終導(dǎo)致權(quán)限數(shù)據(jù)不一致。生產(chǎn)環(huán)境直接用Redis省事也可靠。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 權(quán)限明明加了卻總校驗(yàn)失敗這是我遇到最多的問(wèn)題場(chǎng)景通常是“給角色勾選了某個(gè)權(quán)限前端菜單也顯示了但調(diào)接口還是403”。排查路徑一般按下面幾步走確認(rèn)當(dāng)前登錄的用戶(hù)其角色是否真的已經(jīng)關(guān)聯(lián)到該接口對(duì)應(yīng)的權(quán)限標(biāo)識(shí)。很多情況是權(quán)限標(biāo)識(shí)寫(xiě)錯(cuò)了比如接口校驗(yàn)的是system:user:add菜單按鈕綁定的是system:User:add大小寫(xiě)不一致直接匹配失敗。確認(rèn)是否有緩存。如果有Redis緩存先手動(dòng)清一下該用戶(hù)的緩存鍵再重新調(diào)用接口。確認(rèn)是否走的是超級(jí)管理員邏輯。is_superuserTrue的用戶(hù)在部分實(shí)現(xiàn)里會(huì)被直接放行如果業(yè)務(wù)希望超級(jí)管理員也需要綁定角色要注意代碼分支。一個(gè)比較穩(wěn)妥的習(xí)慣是在權(quán)限校驗(yàn)代碼里臨時(shí)打印當(dāng)前用戶(hù)的權(quán)限集合再打印接口需要的權(quán)限標(biāo)識(shí)一眼就能看出問(wèn)題在哪。logger.debug(fcurrent user perms: {request.user.get_all_permissions()}) logger.debug(frequire perm: {perm_code})5.2 超級(jí)用戶(hù)權(quán)限處理誤區(qū)Django的is_superuser是一個(gè)“一票通過(guò)”的開(kāi)關(guān)默認(rèn)情況下他擁有所有權(quán)限。但在RBAC落地時(shí)存在兩個(gè)容易出問(wèn)題的地方。第一個(gè)是“頁(yè)面和菜單渲染”。如果前端拿到is_superuser就直接返回全部菜單那角色配置功能就完全用不上了可如果超級(jí)管理員連菜單都要跟著角色走又容易漏配導(dǎo)致他自己也看不到某些管理入口。我通常的取舍是超級(jí)管理員直接返回全部菜單和全部權(quán)限但前端在“用戶(hù)管理”和“角色管理”頁(yè)面仍然可以按角色查詢(xún)普通用戶(hù)實(shí)現(xiàn)視角分離。第二個(gè)是“數(shù)據(jù)權(quán)限”。超級(jí)管理員的數(shù)據(jù)權(quán)限一般默認(rèn)為“全部數(shù)據(jù)”但普通角色即使有權(quán)限標(biāo)識(shí)數(shù)據(jù)范圍也可能限制為“僅本人”。所以在查詢(xún)列表數(shù)據(jù)時(shí)除了權(quán)限校驗(yàn)還要額外根據(jù)角色data_scope進(jìn)行數(shù)據(jù)范圍過(guò)濾這一步超級(jí)管理員是直接全部放行的。我把這兩個(gè)邏輯串起來(lái)講是想強(qiáng)調(diào)權(quán)限校驗(yàn)和數(shù)據(jù)范圍過(guò)濾是兩個(gè)完全不同的層級(jí)千萬(wàn)不要混在同一個(gè)函數(shù)里判斷否則很容易出現(xiàn)“有權(quán)限看見(jiàn)按鈕卻看不到按鈕背后的任何數(shù)據(jù)”這種怪異現(xiàn)象。5.3 多角色權(quán)限合并與優(yōu)先級(jí)沖突實(shí)際業(yè)務(wù)里一個(gè)用戶(hù)往往有多種身份既是項(xiàng)目成員又是部門(mén)經(jīng)理還可能兼任某個(gè)專(zhuān)員。這時(shí)權(quán)限集合不是“取最新一個(gè)角色”而是“所有角色權(quán)限的并集”。我常用的模型是“一用戶(hù)多角色”在權(quán)限集合采用set進(jìn)行合并天然去重。但如果不同角色的同一個(gè)權(quán)限標(biāo)識(shí)對(duì)應(yīng)的數(shù)據(jù)范圍不同例如“項(xiàng)目成員”只能看個(gè)人數(shù)據(jù)“部門(mén)經(jīng)理”能看本部門(mén)數(shù)據(jù)這時(shí)簡(jiǎn)單的并集無(wú)法表達(dá)。我采用的方案是數(shù)據(jù)范圍取所有角色中的“最大范圍”比如其中一個(gè)角色是“全部數(shù)據(jù)”那這個(gè)用戶(hù)的數(shù)據(jù)范圍就是“全部數(shù)據(jù)”如果一個(gè)是“本部門(mén)”一個(gè)是“僅本人”那就取“本部門(mén)”。這個(gè)策略在大多數(shù)業(yè)務(wù)場(chǎng)景下都能說(shuō)得通而且實(shí)現(xiàn)起來(lái)也簡(jiǎn)單。如果你遇到的要求是“不同數(shù)據(jù)范圍都要能單獨(dú)限制到某個(gè)菜單”那RBAC基礎(chǔ)模型就有點(diǎn)不夠用了建議引入“數(shù)據(jù)權(quán)限規(guī)則表”在RBAC上層增加一個(gè)策略引擎。但這個(gè)復(fù)雜度一般項(xiàng)目不會(huì)用到我在這里只提一句。5.4 排查命令速查最后把我在排查Django RBAC問(wèn)題時(shí)常用的一些命令和SQL整理成速查表方便你直接抄。場(chǎng)景排查命令確認(rèn)用戶(hù)角色python manage.py shell里執(zhí)行user.roles.all()確認(rèn)角色權(quán)限r(nóng)ole.permissions.values_list(codename, flatTrue)確認(rèn)菜單權(quán)限標(biāo)識(shí)Menu.objects.filter(perms__isnullFalse).values_list(perms, flatTrue)清空某個(gè)用戶(hù)的權(quán)限緩存cache.delete(rbac:perms:user:12)強(qiáng)制遷移構(gòu)建表python manage.py makemigrations system python manage.py migrate查看接口路由對(duì)應(yīng)視圖python manage.py show_urls或查項(xiàng)目的urls.py這些操作基本覆蓋了日常權(quán)限模塊的調(diào)試場(chǎng)景。每次遇到問(wèn)題先做數(shù)據(jù)層面的核對(duì)再考慮代碼邏輯最后懷疑緩存基本能解決90%的問(wèn)題。最后再分享一個(gè)小技巧權(quán)限標(biāo)識(shí)的命名和菜單路由最好在項(xiàng)目啟動(dòng)前就規(guī)劃好而不是邊寫(xiě)邊取。你可以先畫(huà)一張“系統(tǒng)功能權(quán)限清單”表格列出功能模塊、菜單路徑、按鈕名稱(chēng)、權(quán)限標(biāo)識(shí)、對(duì)應(yīng)接口評(píng)審?fù)ㄟ^(guò)后再落到代碼里。很多權(quán)限混亂的爛攤子根源不在代碼而在沒(méi)有一個(gè)清晰的權(quán)限臺(tái)賬。我后來(lái)維護(hù)這套R(shí)BAC模塊時(shí)總是一邊查代碼一邊對(duì)著這臺(tái)賬看自己都沒(méi)想到能省這么多時(shí)間。 Django RBAC權(quán)限管理實(shí)戰(zhàn)：模型設(shè)計(jì)、校驗(yàn)實(shí)現(xiàn)與性能優(yōu)化
做后端的人都繞不過(guò)權(quán)限管理這關(guān)。早幾年我在某公司負(fù)責(zé)一個(gè)后臺(tái)管理系統(tǒng)業(yè)務(wù)功能加了一堆用戶(hù)角色越來(lái)越亂每次梳理權(quán)限都在加班補(bǔ)窟窿。那段時(shí)間我光是整理權(quán)限清單就要花小半天更別提上線(xiàn)之后各種“這個(gè)功能明明能用換個(gè)賬號(hào)就報(bào)403”的反饋。后來(lái)花了兩個(gè)晚上把整個(gè)項(xiàng)目的權(quán)限模塊推倒重來(lái)用RBAC模型重新建模才徹底把這塊理順了。如果你也在用Django做后臺(tái)系統(tǒng)或者正準(zhǔn)備給項(xiàng)目加權(quán)限控制這篇就把我的方案、踩過(guò)的坑、以及排查思路完整講一遍。Django自帶的auth應(yīng)用里其實(shí)已經(jīng)有Group用戶(hù)組和Permission權(quán)限兩張表也能做到基于角色的粗粒度控制但真正落到業(yè)務(wù)里你會(huì)發(fā)現(xiàn)原生的東西離“夠用”還差得遠(yuǎn)。比如“菜單級(jí)權(quán)限”“按鈕級(jí)權(quán)限”“不同部門(mén)的相同角色擁有不同數(shù)據(jù)范圍”這些需求光靠Django原生那套很難優(yōu)雅實(shí)現(xiàn)。所以我基于RBAC的核心思想在Django上做了一套更完整的權(quán)限體系包含用戶(hù)、角色、權(quán)限、菜單四個(gè)維度下面從設(shè)計(jì)思路開(kāi)始逐個(gè)拆解。1. RBAC權(quán)限模型的設(shè)計(jì)思路1.1 RBAC到底解決了什么問(wèn)題在RBACRole-Based Access Control基于角色的訪(fǎng)問(wèn)控制之前很多小項(xiàng)目用的是最原始的方式在用戶(hù)表里直接存“是不是管理員”“能不能導(dǎo)出”“能不能刪數(shù)據(jù)”之類(lèi)的布爾字段。用戶(hù)少的時(shí)候沒(méi)什么用戶(hù)一多、功能一多就亂了——今天A要加一個(gè)導(dǎo)出權(quán)限明天B也要加后天發(fā)現(xiàn)C不該有但代碼里已經(jīng)寫(xiě)死了判斷邏輯只能頻繁改代碼、改數(shù)據(jù)庫(kù)最后誰(shuí)都不敢動(dòng)權(quán)限相關(guān)的東西。RBAC的核心思路是引入“角色”這個(gè)中間層。用戶(hù)不直接綁定權(quán)限而是綁定角色角色再擁有權(quán)限。這樣一來(lái)權(quán)限的分配變成角色與權(quán)限的配置而不再需要頻繁修改用戶(hù)代碼或表結(jié)構(gòu)。類(lèi)比一下一家公司的門(mén)禁卡系統(tǒng)員工不是直接擁有“進(jìn)財(cái)務(wù)室”的權(quán)利而是因?yàn)椤柏?cái)務(wù)部員工”這個(gè)崗位角色天然就被授權(quán)進(jìn)入了財(cái)務(wù)室。換崗的時(shí)候只需要換角色不需要挨個(gè)改門(mén)禁記錄。加上“角色”這層抽象之后權(quán)限管理從“點(diǎn)對(duì)點(diǎn)”變成了“面到面”數(shù)據(jù)集小、邏輯清晰、可追溯。這就是RBAC能成為主流權(quán)限方案的根本原因。1.2 為什么最終選了RBAC而不是ACL或ABAC做權(quán)限選型的時(shí)候市面上主要有三種模型ACLAccess Control List、RBACRole-Based Access Control、ABACAttribute-Based Access Control。ACL是最樸素的思路——直接把某個(gè)用戶(hù)和某種操作權(quán)限掛上鉤。適合小型工單系統(tǒng)、個(gè)人博客后臺(tái)但一旦用戶(hù)量上百、功能上百ACL表的膨脹速度非常驚人而且無(wú)法自然表達(dá)“一類(lèi)人”的共性權(quán)限。ABAC則更靈活用屬性規(guī)則來(lái)判斷比如說(shuō)“銷(xiāo)售部門(mén)的員工只能看本部門(mén)客戶(hù)的工單”但要維護(hù)規(guī)則引擎、表達(dá)式解析復(fù)雜度直接上一個(gè)臺(tái)階中小型項(xiàng)目一般是hold不住的。所以在絕大多數(shù)管理后臺(tái)、中后臺(tái)系統(tǒng)的場(chǎng)景里RBAC是性?xún)r(jià)比最高的方案。它管住了“誰(shuí)能做什么”又不像ABAC那樣引入巨大的規(guī)則復(fù)雜度。而如果后面又出現(xiàn)“不同角色只能看不同部門(mén)數(shù)據(jù)”這種行級(jí)數(shù)據(jù)權(quán)限需求也完全可以在RBAC的基礎(chǔ)上增加一個(gè)數(shù)據(jù)范圍字段來(lái)配合實(shí)現(xiàn)不需要推翻整體設(shè)計(jì)。這也是我在實(shí)操中最終選擇RBAC并保留擴(kuò)展空間的原因。1.3 Django自帶的auth權(quán)限體系夠不夠用凡是開(kāi)過(guò)Django項(xiàng)目的人都知道django.contrib.auth里已經(jīng)提供了User、Group、Permission還自帶has_perm()方法和permission_required裝飾器。那為什么我還要自己再擼一套R(shí)BAC因?yàn)樵脑O(shè)計(jì)目標(biāo)是“給Django管理后臺(tái)admin提供權(quán)限控制”而不是直接給業(yè)務(wù)系統(tǒng)做權(quán)限中臺(tái)。它的問(wèn)題主要集中在幾點(diǎn)第一權(quán)限粒度是按模型來(lái)的一個(gè)Permission對(duì)應(yīng)“添加/修改/刪除/查看某個(gè)模型”但你做業(yè)務(wù)系統(tǒng)時(shí)會(huì)有“導(dǎo)出報(bào)表”“審批工單”“分配任務(wù)”這類(lèi)跟模型CRUD不對(duì)應(yīng)的操作權(quán)限原生比較難表達(dá)。第二菜單和接口權(quán)限沒(méi)有天然建模。你做的是帶側(cè)邊欄的后臺(tái)側(cè)邊欄菜單誰(shuí)可見(jiàn)誰(shuí)不可見(jiàn)原生完全不管需要自己去查詢(xún)、渲染。第三Group雖然可以作為角色表用但它只能關(guān)聯(lián)權(quán)限不能掛級(jí)聯(lián)的數(shù)據(jù)范圍、角色層級(jí)、排序等擴(kuò)展字段使用起來(lái)限制很大。所以實(shí)操中我保留了Django原生的Permission來(lái)承接原子操作權(quán)限再用自定義的Role、Menu等模型來(lái)承載業(yè)務(wù)權(quán)限結(jié)構(gòu)。原生框架的理念值得沿用但必須做擴(kuò)展才能真正支撐起一個(gè)靈活的后臺(tái)權(quán)限系統(tǒng)。2. 數(shù)據(jù)模型與表結(jié)構(gòu)設(shè)計(jì)2.1 五張核心表的職責(zé)劃分在給后臺(tái)系統(tǒng)設(shè)計(jì)RBAC表結(jié)構(gòu)時(shí)我最終拆出了五張核心表外加兩張關(guān)聯(lián)中間表。五張核心表的職責(zé)非常清晰User用戶(hù)表直接用Django的AbstractUser擴(kuò)展增加外鍵關(guān)聯(lián)到角色也可保留原生的多對(duì)多關(guān)系。Role角色表存儲(chǔ)角色名稱(chēng)、角色標(biāo)識(shí)符、排序、狀態(tài)、數(shù)據(jù)范圍等。Permission權(quán)限表存儲(chǔ)權(quán)限編碼、名稱(chēng)可以直接沿用Django自帶的Permission也可以自定義一張權(quán)限表看項(xiàng)目規(guī)模。Menu菜單表存儲(chǔ)系統(tǒng)菜單、按鈕包括菜單類(lèi)型目錄/菜單/按鈕、路由地址、權(quán)限標(biāo)識(shí)等。MenuRole、RoleUser關(guān)聯(lián)表由于角色和菜單、角色和用戶(hù)都是多對(duì)多關(guān)系所以需要中間表來(lái)維護(hù)。這里有個(gè)關(guān)鍵取舍我是直接用Django的Permission還是另建一張Permission表如果你的項(xiàng)目是在Django Admin體系內(nèi)做管理直接復(fù)用即可但如果你要寫(xiě)一個(gè)獨(dú)立的后臺(tái)管理系統(tǒng)我更建議自定義Permission表或菜單表自帶權(quán)限標(biāo)識(shí)因?yàn)槟愫笃跁?huì)有大量“查詢(xún)權(quán)限是否存在”“校驗(yàn)?zāi)硞€(gè)請(qǐng)求URL是否匹配某個(gè)權(quán)限標(biāo)識(shí)”的場(chǎng)景自己的表更靈活可控不用跟Django的ContentType混在一起。下面給出我實(shí)際使用的一套模型定義。2.2 核心模型代碼實(shí)例先擴(kuò)展用戶(hù)模型。用AbstractUser加一個(gè)roles多對(duì)多字段兼容Django原本的groups和user_permissions。from django.contrib.auth.models import AbstractUser, Permission from django.db import models class User(AbstractUser): 擴(kuò)展用戶(hù)表增加與角色的多對(duì)多關(guān)系 roles models.ManyToManyField( Role, throughUserRole, related_nameusers, blankTrue, verbose_name角色列表 ) # 如果業(yè)務(wù)需要可以增加部門(mén)、崗位等字段 department models.CharField(max_length64, blankTrue, verbose_name部門(mén)) class Meta(AbstractUser.Meta): verbose_name 用戶(hù) verbose_name_plural verbose_name然后是Role模型給角色增加數(shù)據(jù)范圍和狀態(tài)等擴(kuò)展字段。class Role(models.Model): 角色表 DATA_SCOPE_CHOICES [ (1, 全部數(shù)據(jù)), (2, 本部門(mén)及以下), (3, 僅本部門(mén)), (4, 僅本人), ] name models.CharField(max_length64, uniqueTrue, verbose_name角色名稱(chēng)) code models.CharField(max_length64, uniqueTrue, verbose_name角色標(biāo)識(shí)) data_scope models.IntegerField(choicesDATA_SCOPE_CHOICES, default3, verbose_name數(shù)據(jù)范圍) status models.BooleanField(defaultTrue, verbose_name狀態(tài)) sort models.IntegerField(default0, verbose_name排序) permissions models.ManyToManyField(Permission, blankTrue, verbose_name權(quán)限列表) desc models.CharField(max_length256, blankTrue, verbose_name角色描述) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.name class Meta: db_table system_role verbose_name 角色 verbose_name_plural verbose_name這里要注意permissions字段與Django原生的Permission建立多對(duì)多關(guān)系這樣一方面可以兼容has_perm相關(guān)的邏輯另一方面也給權(quán)限的批量管理留好了口子。接下來(lái)是Menu表。它承載了兩個(gè)功能一是后臺(tái)側(cè)邊欄菜單的渲染二是按鈕級(jí)權(quán)限的判斷。因?yàn)楹芏鄼?quán)限校驗(yàn)最終都落到“某個(gè)按鈕標(biāo)識(shí)是否在用戶(hù)的權(quán)限集合里”所以菜單表需要一個(gè)唯一的perms字段來(lái)標(biāo)識(shí)。class Menu(models.Model): 菜單與按鈕權(quán)限表 MENU_TYPE_CHOICES [ (1, 目錄), (2, 菜單), (3, 按鈕), ] parent models.ForeignKey( self, on_deletemodels.CASCADE, nullTrue, blankTrue, related_namechildren, verbose_name父級(jí)菜單 ) name models.CharField(max_length64, verbose_name菜單名稱(chēng)) path models.CharField(max_length255, blankTrue, verbose_name路由地址) component models.CharField(max_length255, blankTrue, verbose_name前端組件路徑) perms models.CharField(max_length255, blankTrue, verbose_name權(quán)限標(biāo)識(shí)) type models.IntegerField(choicesMENU_TYPE_CHOICES, default2, verbose_name菜單類(lèi)型) icon models.CharField(max_length128, blankTrue, verbose_name圖標(biāo)) sort models.IntegerField(default0, verbose_name排序) visible models.BooleanField(defaultTrue, verbose_name是否顯示) status models.BooleanField(defaultTrue, verbose_name狀態(tài)) roles models.ManyToManyField(Role, throughMenuRole, related_namemenus, blankTrue, verbose_name角色列表) class Meta: db_table system_menu verbose_name 菜單 verbose_name_plural verbose_name def __str__(self): return self.name最后是兩個(gè)中間表。雖然Django會(huì)自動(dòng)生成但我需要給中間表增加自定義字段所以顯式寫(xiě)出來(lái)。class UserRole(models.Model): 用戶(hù)-角色中間表 user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameuser_roles) role models.ForeignKey(Role, on_deletemodels.CASCADE, related_nameuser_roles) class MenuRole(models.Model): 角色-菜單中間表 role models.ForeignKey(Role, on_deletemodels.CASCADE, related_namemenu_roles) menu models.ForeignKey(Menu, on_deletemodels.CASCADE, related_namemenu_roles) class Meta: unique_together (role, menu)從實(shí)操角度看這樣的模型設(shè)計(jì)已經(jīng)能覆蓋95%以上后臺(tái)系統(tǒng)的權(quán)限需求。如果還要再升級(jí)可以將User和Role改成多對(duì)多扁平結(jié)構(gòu)允許一個(gè)用戶(hù)擁有多個(gè)角色數(shù)據(jù)權(quán)限則可以借助data_scope字段在查詢(xún)中動(dòng)態(tài)拼接SQL或ORM過(guò)濾條件。2.3 表關(guān)系與預(yù)置數(shù)據(jù)規(guī)劃表關(guān)系上整體是典型的“星型結(jié)構(gòu)”用戶(hù)表在中心左邊連著角色右邊連著權(quán)限菜單表作為前端渲染和權(quán)限標(biāo)識(shí)的錨點(diǎn)和角色建立關(guān)聯(lián)。為了讓查詢(xún)性能更好我在Role里直接持有permissions多對(duì)多關(guān)系在Menu里直接持有roles多對(duì)多關(guān)系這樣查詢(xún)用戶(hù)時(shí)可以先拿到角色再由角色快速關(guān)聯(lián)到菜單和權(quán)限。初始化數(shù)據(jù)時(shí)建議做一個(gè)基礎(chǔ)數(shù)據(jù)腳本用Django的management command來(lái)跑不要手動(dòng)往庫(kù)里插否則環(huán)境差異很容易造成數(shù)據(jù)不一致。一個(gè)典型的初始化流程是創(chuàng)建超級(jí)管理員角色并綁定所有權(quán)限標(biāo)識(shí)。創(chuàng)建通用角色如普通用戶(hù)、運(yùn)維只讀角色綁定對(duì)應(yīng)的菜單和權(quán)限。創(chuàng)建系統(tǒng)的菜單結(jié)構(gòu)目錄、菜單、按鈕三個(gè)層級(jí)分開(kāi)錄入。把默認(rèn)的超級(jí)管理員的用戶(hù)ID與角色綁定。我自己實(shí)際跑起來(lái)的時(shí)候發(fā)現(xiàn)最費(fèi)時(shí)間的不是寫(xiě)模型而是整理菜單和權(quán)限標(biāo)識(shí)的清單。這個(gè)清單直接決定后續(xù)權(quán)限管理的易用性。權(quán)限標(biāo)識(shí)的命名我建議統(tǒng)一用冒號(hào)分層例如system:user:add、system:user:edit、system:user:delete。這樣正則匹配容易前端按鈕和后端接口校驗(yàn)也好統(tǒng)一對(duì)。3. 實(shí)操落地權(quán)限校驗(yàn)完整實(shí)現(xiàn)3.1 項(xiàng)目初始化與配置第一步自然是搭一個(gè)可運(yùn)行的Django項(xiàng)目。我習(xí)慣先用獨(dú)立的目錄把項(xiàng)目建好再逐步合入權(quán)限模塊?；A(chǔ)配置里需要把自定義用戶(hù)模型設(shè)置好在settings.py里加AUTH_USER_MODEL然后注冊(cè)到INSTALLED_APPS。# settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, # 如果走API型后臺(tái)建議集成DRF system, # 權(quán)限所在的業(yè)務(wù)模塊 ] AUTH_USER_MODEL system.User我用Django REST Framework的原因是當(dāng)前后臺(tái)管理基本都是前后端分離的后端只提供JSON接口權(quán)限校驗(yàn)放在視圖層和中間件層。如果不打算前后端分離也可以忽略DRF直接用View和模板渲染菜單。隨后執(zhí)行遷移命令確認(rèn)模型建表沒(méi)問(wèn)題。python manage.py makemigrations python manage.py migrate這個(gè)時(shí)候有個(gè)非常容易踩的坑如果你是在已有項(xiàng)目上引入AUTH_USER_MODEL數(shù)據(jù)庫(kù)里可能已經(jīng)有了其他表的外鍵關(guān)聯(lián)到原生的auth.User遷移會(huì)直接報(bào)錯(cuò)。解決方法是先確保被關(guān)聯(lián)的表比如日志表、工單表要么用settings.AUTH_USER_MODEL做外鍵要么在引入之前處理好懸空外鍵的問(wèn)題。3.2 權(quán)限校驗(yàn)裝飾器與中間件有了模型之后最核心的部分就是把“權(quán)限標(biāo)識(shí)”和“接口請(qǐng)求”關(guān)聯(lián)起來(lái)。我封了一個(gè)裝飾器permission_check用于視圖函數(shù)或DRF視圖類(lèi)。from django.http import JsonResponse from functools import wraps def permission_check(perm_code): 簡(jiǎn)單的權(quán)限校驗(yàn)裝飾器支持DRF視圖 def decorator(view_func): wraps(view_func) def wrapped_view(request, *args, **kwargs): if not request.user.is_authenticated: return JsonResponse({code: 401, msg: 未登錄}, status401) if request.user.is_superuser: return view_func(request, *args, **kwargs) # 從request中取出用戶(hù)擁有的權(quán)限集合 perm_set request.user.get_all_permissions() if perm_code not in perm_set: return JsonResponse({code: 403, msg: 無(wú)權(quán)限訪(fǎng)問(wèn)}, status403) return view_func(request, *args, **kwargs) return wrapped_view return decorator permission_check(system:user:add) def add_user(request): # 新增用戶(hù)邏輯 pass這里的關(guān)鍵點(diǎn)在于request.user.get_all_permissions()為了讓它每次都返回最新權(quán)限我在User模型上自定義了一個(gè)方法。這個(gè)方法的核心邏輯是從當(dāng)前用戶(hù)關(guān)聯(lián)的角色找到這些角色綁定的權(quán)限收集所有權(quán)限編碼。from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): roles models.ManyToManyField(Role, throughUserRole, related_nameusers, blankTrue) def get_all_permissions(self): if self.is_superuser: # 超級(jí)管理員直接返回一個(gè)始終包含通過(guò)的標(biāo)記 return {*,} # 通過(guò)角色收集權(quán)限編碼 perms set() role_ids self.roles.filter(statusTrue).values_list(id, flatTrue) for role_id in role_ids: # 從Role關(guān)聯(lián)到Permission permissions Role.objects.get(pkrole_id).permissions.all() for p in permissions: perms.add(p.codename) # 如果還涉及菜單表權(quán)限標(biāo)識(shí) menu_perm Menu.objects.filter(roles__id__inrole_ids, perms__isnullFalse).values_list(perms, flatTrue) perms.update(menu_perm) return perms這里有一個(gè)容易混淆的點(diǎn)Django原生Permission自帶codename這個(gè)codename是像add_userchange_user這樣的短名稱(chēng)但為了方便統(tǒng)一控制我更建議直接把權(quán)限標(biāo)識(shí)寫(xiě)入codename或新建一個(gè)字段比如system:user:add。實(shí)際項(xiàng)目中為了讓菜單權(quán)限和后端權(quán)限共用一個(gè)權(quán)限集合下面這段邏輯是主流做法。不過(guò)要注意get_all_permissions這個(gè)方法是DjangoBaseUser里就存在的鉤子我在覆寫(xiě)時(shí)保留一致的返回類(lèi)型后面很多內(nèi)置功能都不會(huì)出問(wèn)題。如果不想在每一個(gè)視圖函數(shù)上加裝飾器也可以在中間件層做統(tǒng)一攔截。以下是我常用的一個(gè)輕量中間件它把“白名單 登錄態(tài)”自動(dòng)處理了。class RbacMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): # 對(duì)不需要權(quán)限校驗(yàn)的路由放行 path request.path allow_list [ /api/login/, /api/captcha/, /static/, ] if any(path.startswith(prefix) for prefix in allow_list): return self.get_response(request) if not request.user.is_authenticated: return JsonResponse({code: 401, msg: 未登錄}, status401) # 判斷當(dāng)前請(qǐng)求的URL是否需要“資源權(quán)限”校驗(yàn) # 通過(guò)一個(gè)服務(wù)函數(shù)獲取 URL - 權(quán)限標(biāo)識(shí) 的映射關(guān)系 perm_code matcher.get_permission_by_path(path) if perm_code and not request.user.is_superuser: if perm_code not in request.user.get_all_permissions(): return JsonResponse({code: 403, msg: 無(wú)權(quán)限訪(fǎng)問(wèn)}, status403) return self.get_response(request)用中間件的好處是接口不用逐個(gè)加裝飾器新增接口只要在路由配置的時(shí)候做好權(quán)限標(biāo)識(shí)和路徑的映射就行。但它也有一個(gè)劣勢(shì)——每個(gè)請(qǐng)求都會(huì)跑一遍權(quán)限檢查對(duì)性能有一定影響所以通常會(huì)和緩存方案配合使用。后面第4章我會(huì)專(zhuān)門(mén)講性能優(yōu)化。3.3 前端菜單與按鈕級(jí)權(quán)限控制做后臺(tái)管理系統(tǒng)前端核心訴求就兩個(gè)菜單按角色動(dòng)態(tài)渲染按鈕按權(quán)限動(dòng)態(tài)顯示。前端拿到當(dāng)前用戶(hù)后調(diào)用一個(gè)獲取用戶(hù)信息的接口接口返回該用戶(hù)可見(jiàn)的菜單樹(shù)和權(quán)限標(biāo)識(shí)集合。在Django視圖里獲取菜單樹(shù)的邏輯大概是這樣的def get_user_menu_tree(request): user request.user if user.is_superuser: menus Menu.objects.filter(statusTrue, type__in[1, 2]).order_by(sort) else: role_ids user.roles.filter(statusTrue).values_list(id, flatTrue) menus Menu.objects.filter(roles__id__inrole_ids, statusTrue, type__in[1, 2]).order_by(sort) tree build_menu_tree(menus) return JsonResponse({code: 200, data: tree}) def build_menu_tree(menus): 將扁平的菜單列表轉(zhuǎn)換為樹(shù)形結(jié)構(gòu) menu_list list(menus.values(id, parent_id, name, path, component, icon, sort, type)) tree [] # 轉(zhuǎn)化為dict便于快速查找 menu_map {} for item in menu_list: parent_id item.pop(parent_id) item[children] [] menu_map[item[id]] item # 組裝樹(shù) for item in menu_list: item.pop(parent_id, None) return menu_list上面的代碼為了簡(jiǎn)化示例我忽略了遞歸組樹(shù)的過(guò)程實(shí)際需要遞歸根據(jù)parent_id掛到對(duì)應(yīng)的children里。前端拿到這棵菜單樹(shù)之后直接遍歷渲染側(cè)邊欄即可。按鈕級(jí)權(quán)限同理接口返回一個(gè)扁平的權(quán)限標(biāo)識(shí)列表前端在按鈕上判斷const hasPerm (perm) { return store.state.permissions.includes(perm); }這樣就能實(shí)現(xiàn)“角色變了按鈕自動(dòng)隱藏”的效果。需要注意的是前端權(quán)限控制只是體驗(yàn)優(yōu)化真正的安全防線(xiàn)永遠(yuǎn)在后端。接口和數(shù)據(jù)的權(quán)限校驗(yàn)不能因?yàn)榍岸穗[藏了入口就省略一定要在視圖層再校驗(yàn)一次防止有人直接請(qǐng)求接口地址。4. 性能優(yōu)化與緩存方案4.1 權(quán)限查詢(xún)的N1問(wèn)題RBAC模型在實(shí)現(xiàn)之后最容易暴露的問(wèn)題就是查詢(xún)性能。原因很簡(jiǎn)單用戶(hù) - 角色 - 權(quán)限 - 菜單是多層關(guān)聯(lián)如果不做優(yōu)化一次權(quán)限查詢(xún)會(huì)實(shí)時(shí)發(fā)起大量SQL。舉個(gè)例子如果用戶(hù)有3個(gè)角色每個(gè)角色有20個(gè)權(quán)限標(biāo)識(shí)那么獲取用戶(hù)全部權(quán)限時(shí)如果用遍歷角色的方式逐個(gè)查詢(xún)權(quán)限SQL次數(shù)就是“1次查角色 N次查權(quán)限”。在用戶(hù)登錄、用戶(hù)訪(fǎng)問(wèn)接口、獲取菜單樹(shù)這些關(guān)鍵節(jié)點(diǎn)都會(huì)被放大多倍。解決方案有兩個(gè)層面。第一個(gè)層面是使用prefetch_related預(yù)取關(guān)聯(lián)數(shù)據(jù)在查詢(xún)角色列表時(shí)就把每個(gè)角色的權(quán)限集合一次性取出來(lái)例如roles Role.objects.filter(statusTrue).prefetch_related(permissions)第二個(gè)層面更徹底——把權(quán)限集合做緩存不用每次請(qǐng)求都去數(shù)據(jù)庫(kù)里查。4.2 緩存策略與Redis集成考慮到權(quán)限數(shù)據(jù)的特點(diǎn)是“讀多寫(xiě)少”非常適合用緩存。我在項(xiàng)目里把用戶(hù)權(quán)限集合、菜單樹(shù)都放到了Redis里緩存前綴按用戶(hù)ID區(qū)分例如rbac:perms:user:{user_id}緩存時(shí)間設(shè)為30分鐘。集成Redis之后get_all_permissions()的改造邏輯是這樣的from django.core.cache import cache def get_all_permissions(self): cache_key frbac:perms:user:{self.id} perms cache.get(cache_key) if perms is not None: return perms # 未命中則從數(shù)據(jù)庫(kù)查詢(xún) if self.is_superuser: perms {*,} else: perms set() role_list self.roles.filter(statusTrue).prefetch_related(permissions) for role in role_list: for p in role.permissions.all(): perms.add(p.codename) # 補(bǔ)充菜單權(quán)限標(biāo)識(shí) menu_perms Menu.objects.filter( roles__id__inself.roles.filter(statusTrue), perms__isnullFalse ).values_list(perms, flatTrue) perms.update(menu_perms) # 寫(xiě)入緩存 cache.set(cache_key, perms, timeout1800) return perms這里有個(gè)細(xì)節(jié)perms是無(wú)序集合在緩存時(shí)要注意cache.set能否接受set類(lèi)型。大部分Redis緩存后端會(huì)自動(dòng)把set序列化成list取回來(lái)就變成list了所以最好在寫(xiě)入前統(tǒng)一list(perms)讀取時(shí)再轉(zhuǎn)成集合避免類(lèi)型不一致導(dǎo)致后續(xù)in判斷出錯(cuò)。另外我強(qiáng)烈建議把緩存的鍵設(shè)計(jì)成可控制的版本號(hào)比如rbac:perms:user:{user_id}:v2。這樣當(dāng)權(quán)限邏輯升級(jí)時(shí)只需要改版本號(hào)讓舊緩存自然失效避免老用戶(hù)因?yàn)榕f緩存一直看到舊的權(quán)限數(shù)據(jù)。4.3 權(quán)限變更即時(shí)生效緩存能提升性能但也帶來(lái)一個(gè)常見(jiàn)問(wèn)題管理員修改了角色權(quán)限用戶(hù)的緩存卻沒(méi)有及時(shí)刷新導(dǎo)致新權(quán)限遲遲不生效。解決辦法是在權(quán)限變更的業(yè)務(wù)邏輯里主動(dòng)清除對(duì)應(yīng)用戶(hù)的緩存。實(shí)際處理時(shí)我封裝了一個(gè)服務(wù)類(lèi)專(zhuān)門(mén)負(fù)責(zé)角色權(quán)限的修改與緩存清理class RbacService: staticmethod def assign_permissions_to_role(role, perm_codes): 給角色分配權(quán)限 # 處理權(quán)限編碼的更新 role.permissions.clear() ... # 清理所有擁有該角色的用戶(hù)的緩存 user_ids role.users.values_list(user_id, flatTrue) for user_id in user_ids: cache_key frbac:perms:user:{user_id} cache.delete(cache_key)有同學(xué)可能會(huì)問(wèn)如果沒(méi)有Redis緩存而是本地內(nèi)存緩存這個(gè)失效怎么處理我建議不要把本地緩存作為核心方案因?yàn)槎噙M(jìn)程部署下本地緩存無(wú)法聯(lián)動(dòng)失效最終導(dǎo)致權(quán)限數(shù)據(jù)不一致。生產(chǎn)環(huán)境直接用Redis省事也可靠。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 權(quán)限明明加了卻總校驗(yàn)失敗這是我遇到最多的問(wèn)題場(chǎng)景通常是“給角色勾選了某個(gè)權(quán)限前端菜單也顯示了但調(diào)接口還是403”。排查路徑一般按下面幾步走確認(rèn)當(dāng)前登錄的用戶(hù)其角色是否真的已經(jīng)關(guān)聯(lián)到該接口對(duì)應(yīng)的權(quán)限標(biāo)識(shí)。很多情況是權(quán)限標(biāo)識(shí)寫(xiě)錯(cuò)了比如接口校驗(yàn)的是system:user:add菜單按鈕綁定的是system:User:add大小寫(xiě)不一致直接匹配失敗。確認(rèn)是否有緩存。如果有Redis緩存先手動(dòng)清一下該用戶(hù)的緩存鍵再重新調(diào)用接口。確認(rèn)是否走的是超級(jí)管理員邏輯。is_superuserTrue的用戶(hù)在部分實(shí)現(xiàn)里會(huì)被直接放行如果業(yè)務(wù)希望超級(jí)管理員也需要綁定角色要注意代碼分支。一個(gè)比較穩(wěn)妥的習(xí)慣是在權(quán)限校驗(yàn)代碼里臨時(shí)打印當(dāng)前用戶(hù)的權(quán)限集合再打印接口需要的權(quán)限標(biāo)識(shí)一眼就能看出問(wèn)題在哪。logger.debug(fcurrent user perms: {request.user.get_all_permissions()}) logger.debug(frequire perm: {perm_code})5.2 超級(jí)用戶(hù)權(quán)限處理誤區(qū)Django的is_superuser是一個(gè)“一票通過(guò)”的開(kāi)關(guān)默認(rèn)情況下他擁有所有權(quán)限。但在RBAC落地時(shí)存在兩個(gè)容易出問(wèn)題的地方。第一個(gè)是“頁(yè)面和菜單渲染”。如果前端拿到is_superuser就直接返回全部菜單那角色配置功能就完全用不上了可如果超級(jí)管理員連菜單都要跟著角色走又容易漏配導(dǎo)致他自己也看不到某些管理入口。我通常的取舍是超級(jí)管理員直接返回全部菜單和全部權(quán)限但前端在“用戶(hù)管理”和“角色管理”頁(yè)面仍然可以按角色查詢(xún)普通用戶(hù)實(shí)現(xiàn)視角分離。第二個(gè)是“數(shù)據(jù)權(quán)限”。超級(jí)管理員的數(shù)據(jù)權(quán)限一般默認(rèn)為“全部數(shù)據(jù)”但普通角色即使有權(quán)限標(biāo)識(shí)數(shù)據(jù)范圍也可能限制為“僅本人”。所以在查詢(xún)列表數(shù)據(jù)時(shí)除了權(quán)限校驗(yàn)還要額外根據(jù)角色data_scope進(jìn)行數(shù)據(jù)范圍過(guò)濾這一步超級(jí)管理員是直接全部放行的。我把這兩個(gè)邏輯串起來(lái)講是想強(qiáng)調(diào)權(quán)限校驗(yàn)和數(shù)據(jù)范圍過(guò)濾是兩個(gè)完全不同的層級(jí)千萬(wàn)不要混在同一個(gè)函數(shù)里判斷否則很容易出現(xiàn)“有權(quán)限看見(jiàn)按鈕卻看不到按鈕背后的任何數(shù)據(jù)”這種怪異現(xiàn)象。5.3 多角色權(quán)限合并與優(yōu)先級(jí)沖突實(shí)際業(yè)務(wù)里一個(gè)用戶(hù)往往有多種身份既是項(xiàng)目成員又是部門(mén)經(jīng)理還可能兼任某個(gè)專(zhuān)員。這時(shí)權(quán)限集合不是“取最新一個(gè)角色”而是“所有角色權(quán)限的并集”。我常用的模型是“一用戶(hù)多角色”在權(quán)限集合采用set進(jìn)行合并天然去重。但如果不同角色的同一個(gè)權(quán)限標(biāo)識(shí)對(duì)應(yīng)的數(shù)據(jù)范圍不同例如“項(xiàng)目成員”只能看個(gè)人數(shù)據(jù)“部門(mén)經(jīng)理”能看本部門(mén)數(shù)據(jù)這時(shí)簡(jiǎn)單的并集無(wú)法表達(dá)。我采用的方案是數(shù)據(jù)范圍取所有角色中的“最大范圍”比如其中一個(gè)角色是“全部數(shù)據(jù)”那這個(gè)用戶(hù)的數(shù)據(jù)范圍就是“全部數(shù)據(jù)”如果一個(gè)是“本部門(mén)”一個(gè)是“僅本人”那就取“本部門(mén)”。這個(gè)策略在大多數(shù)業(yè)務(wù)場(chǎng)景下都能說(shuō)得通而且實(shí)現(xiàn)起來(lái)也簡(jiǎn)單。如果你遇到的要求是“不同數(shù)據(jù)范圍都要能單獨(dú)限制到某個(gè)菜單”那RBAC基礎(chǔ)模型就有點(diǎn)不夠用了建議引入“數(shù)據(jù)權(quán)限規(guī)則表”在RBAC上層增加一個(gè)策略引擎。但這個(gè)復(fù)雜度一般項(xiàng)目不會(huì)用到我在這里只提一句。5.4 排查命令速查最后把我在排查Django RBAC問(wèn)題時(shí)常用的一些命令和SQL整理成速查表方便你直接抄。場(chǎng)景排查命令確認(rèn)用戶(hù)角色python manage.py shell里執(zhí)行user.roles.all()確認(rèn)角色權(quán)限r(nóng)ole.permissions.values_list(codename, flatTrue)確認(rèn)菜單權(quán)限標(biāo)識(shí)Menu.objects.filter(perms__isnullFalse).values_list(perms, flatTrue)清空某個(gè)用戶(hù)的權(quán)限緩存cache.delete(rbac:perms:user:12)強(qiáng)制遷移構(gòu)建表python manage.py makemigrations system python manage.py migrate查看接口路由對(duì)應(yīng)視圖python manage.py show_urls或查項(xiàng)目的urls.py這些操作基本覆蓋了日常權(quán)限模塊的調(diào)試場(chǎng)景。每次遇到問(wèn)題先做數(shù)據(jù)層面的核對(duì)再考慮代碼邏輯最后懷疑緩存基本能解決90%的問(wèn)題。最后再分享一個(gè)小技巧權(quán)限標(biāo)識(shí)的命名和菜單路由最好在項(xiàng)目啟動(dòng)前就規(guī)劃好而不是邊寫(xiě)邊取。你可以先畫(huà)一張“系統(tǒng)功能權(quán)限清單”表格列出功能模塊、菜單路徑、按鈕名稱(chēng)、權(quán)限標(biāo)識(shí)、對(duì)應(yīng)接口評(píng)審?fù)ㄟ^(guò)后再落到代碼里。很多權(quán)限混亂的爛攤子根源不在代碼而在沒(méi)有一個(gè)清晰的權(quán)限臺(tái)賬。我后來(lái)維護(hù)這套R(shí)BAC模塊時(shí)總是一邊查代碼一邊對(duì)著這臺(tái)賬看自己都沒(méi)想到能省這么多時(shí)間。