Django許可權機制的實現

Gevin發表於2015-11-26

django-permission

本文涉及的技術,已應用於我基於django 1.8+ 開發的部落格系統——MayBlog,歡迎交流。

1. Django許可權機制概述

許可權機制能夠約束使用者行為,控制頁面的顯示內容,也能使API更加安全和靈活;用好許可權機制,能讓系統更加強大和健壯。因此,基於Django的開發,理清Django許可權機制是非常必要的。

1.1 Django的許可權控制

Django用user, group和permission完成了許可權機制,這個許可權機制是將屬於model的某個permission賦予user或group,可以理解為全域性的許可權,即如果使用者A對資料模型(model)B有可寫許可權,那麼A能修改model B的所有例項(objects)。group的許可權也是如此,如果為group C 賦予model B的可寫許可權,則隸屬於group C 的所有使用者,都可以修改model B的所有例項。

這種許可權機制只能解決一些簡單的應用需求,而大部分應用場景下,需要更細分的許可權機制。以部落格系統為例,部落格系統的使用者可分為『管理員』、『編輯』、『作者』和『讀者』四個使用者組;部落格系統管理員和編輯具有檢視、修改和刪除所有的文章的許可權,作者只能修改和刪除自己寫的文章,而讀者則只有閱讀許可權。管理員、編輯和讀者的許可權,我們可以用全域性許可權做控制,而對於作者,全域性許可權無法滿足需求,僅通過全域性許可權,要麼允許作者編輯不屬於自己的文章,要麼讓作者連自己的文章都無法修改。

上述的應用場景,Django自帶的許可權機制無法滿足需求,需要引入另一種更細的許可權機制:物件許可權(object permission)

Object Permission是一種物件顆粒度上的許可權機制,它允許為每個具體物件授權。仍沿用最開始的例子,如果model B有三個例項 B1,B2 和B3,如果我們把B1的可寫許可權賦予使用者A,則A可以修改B1物件,而對B2,B3無法修改。對group也一樣,如果將B2的可寫許可權賦予group C,則隸屬於group C的所有使用者均可以修改B2,但無法修改B1和B3。結合Django自帶許可權機制和object permission,部落格系統中作者的許可權控制迎刃而解:系統全域性上不允許作者編輯文章,而對於屬於作者的具體文章,賦予編輯許可權即可。

Django其實包含了object permission的框架,但沒有具體實現,object permission的實現需要藉助第三方app django-guardian,我們在開發中用呼叫django guradian封裝好的方法即可。

1.2 Django的許可權項

Django用permission物件儲存許可權項,每個model預設都有三個permission,即add model, change model和delete model。例如,定義一個名為『Car』model,定義好Car之後,會自動建立相應的三個permission:add_car, change_cardelete_car。Django還允許自定義permission,例如,我們可以為Car建立新的許可權項:drive_car, clean_car, fix_car等等

需要注意的是,permission總是與model對應的,如果一個object不是model的例項,我們無法為它建立/分配許可權。

2. Django 自帶許可權機制的應用

2.1 Permission

如上文所述,Django定義每個model後,預設都會新增該model的add, change和delete三個permission,自定義的permission可以在我們定義model時手動新增:

每個permission都是django.contrib.auth.Permission型別的例項,該型別包含三個欄位name, codenamecontent_type,其中 content_type反應了permission屬於哪個model,codename如上面的view_task,程式碼邏輯中檢查許可權時要用, name是permission的描述,將permission列印到螢幕或頁面時預設顯示的就是name

在model中建立自定義許可權,從系統開發的角度,可理解為建立系統的內建許可權,如果需求中涉及到使用者使用系統時建立自定義許可權,則要通過下面方法:

2.2 User Permission管理

User物件的user_permission欄位管理使用者的許可權:

檢查使用者許可權用has_perm()方法:

has_perm()方法的引數,即permission的codename,但傳遞引數時需要加上model 所屬app的字首,格式為.

無論permission賦予user還是group,has_perm()方法均適用

附註:

user.get_all_permissions()方法列出使用者的所有許可權,返回值是permission name的list
user.get_group_permissions()方法列出使用者所屬group的許可權,返回值是permission name的list

2.3 Group Permission管理

group permission管理邏輯與user permission管理一致,group中使用permissions欄位做許可權管理:

許可權檢查:

依然使用user.has_perm()方法。

2.4 permission_required 裝飾器

許可權能約束使用者行為,當業務邏輯中涉及到許可權檢查時,decorator能夠分離許可權驗證和核心的業務邏輯,使程式碼更簡潔,邏輯更清晰。permission的decorator為permission_required

2.5 Template中的許可權檢查

Template中使用全域性變數perms儲存當前使用者的所有許可權,許可權檢查可以參考下面例子:

3. 基於Django-guardian的object permission的應用

Django-guardian基於django的原生邏輯擴充套件了django的許可權機制,應用django-guardian後,可以使用django-guardian提供的方法以及django的原生方法檢查全域性許可權,django-guardian提供的object permission機制使django的許可權機制更加完善。

django-guardian詳細的使用文件請參考官方文件,其object permission常用方法如下:

3.1 新增object permission

新增object permission使用assign_perm()方法,如為使用者新增對mycar物件的drive_car許可權:

assign_perm()方法也可用於group

3.2 許可權檢查

3.2.1 Global permission

get_perms()方法用於檢查使用者的“全域性許可權”(global permission),與user.has_perm()異曲同工,如:

例子中雖然把post object作為引數傳給get_perms()方法,但它只檢查user的全域性許可權中是否有main.change_post許可權,很多情況下可用原生的user.has_perm取代,但user和group均可作為get_perms()的傳入引數,某些情況下可以使程式碼更簡潔。

3.2.2 Object permission

Django-guardian中使用ObjectPermissionChecker檢查使用者的object permission,示例如下:

3.3 permission_required裝飾器

guardian.decorators.permission_required是django-guardian許可權檢查的decorator,既可以檢查全域性許可權,又可以檢查物件許可權(object permission),其中,accept_global_perms引數指出是否檢查user的global permission,如:

注:

decorator中的(models.Post, 'id', 'pk')部分,用於指定object例項,如果忽略這個引數,則不論accept_global_perms值為True還是False,均僅僅檢查全域性許可權。

4. 結論

Django原生提供了一種簡單的全域性許可權(global permission)控制機制,但很多應用場景下,物件許可權(object permission)更加有用;django-guardian是目前比較活躍的一個django extension,提供了一種有效的object permission控制機制,與django原生機制一脈相承,推薦使用。

 

相關文章