Django權(quán)限機(jī)制概述

????????權(quán)限機(jī)制能夠約束用戶行為儡循，控制頁面的顯示內(nèi)容混滔，也能使API更加安全和靈活洒疚；用好權(quán)限機(jī)制歹颓，能讓系統(tǒng)更加強(qiáng)大和健壯。因此油湖，基于Django的開發(fā)巍扛，理清Django權(quán)限機(jī)制是非常必要的。

Django的權(quán)限控制

????????Django用user, group和permission完成了權(quán)限機(jī)制乏德，這個權(quán)限機(jī)制是將屬于model的某個permission賦予user或group撤奸，可以理解為全局的權(quán)限，即如果用戶A對數(shù)據(jù)模型（model）B有可寫權(quán)限鹅经，那么A能修改model B的所有實例（objects）寂呛。group的權(quán)限也是如此，如果為group C 賦予model B的可寫權(quán)限瘾晃，則隸屬于group C 的所有用戶贷痪，都可以修改model B的所有實例。

????????這種權(quán)限機(jī)制只能解決一些簡單的應(yīng)用需求蹦误，而大部分應(yīng)用場景下劫拢，需要更細(xì)分的權(quán)限機(jī)制。以博客系統(tǒng)為例强胰，博客系統(tǒng)的用戶可分為『管理員』舱沧、『編輯』、『作者』和『讀者』四個用戶組偶洋；博客系統(tǒng)管理員和編輯具有查看熟吏、修改和刪除所有的文章的權(quán)限，作者只能修改和刪除自己寫的文章玄窝，而讀者則只有閱讀權(quán)限牵寺。管理員、編輯和讀者的權(quán)限恩脂，我們可以用全局權(quán)限做控制帽氓，而對于作者，全局權(quán)限無法滿足需求俩块，僅通過全局權(quán)限黎休，要么允許作者編輯不屬于自己的文章，要么讓作者連自己的文章都無法修改玉凯。

????????上述的應(yīng)用場景势腮，Django自帶的權(quán)限機(jī)制無法滿足需求，需要引入另一種更細(xì)的權(quán)限機(jī)制：對象權(quán)限（object permission）漫仆。

????????Object Permission是一種對象顆粒度上的權(quán)限機(jī)制嫉鲸，它允許為每個具體對象授權(quán)。仍沿用最開始的例子歹啼，如果model B有三個實例 B1玄渗，B2 和B3座菠，如果我們把B1的可寫權(quán)限賦予用戶A，則A可以修改B1對象藤树，而對B2浴滴，B3無法修改。對group也一樣岁钓，如果將B2的可寫權(quán)限賦予group C升略，則隸屬于group C的所有用戶均可以修改B2，但無法修改B1和B3屡限。結(jié)合Django自帶權(quán)限機(jī)制和object permission品嚣，博客系統(tǒng)中作者的權(quán)限控制迎刃而解：系統(tǒng)全局上不允許作者編輯文章，而對于屬于作者的具體文章钧大，賦予編輯權(quán)限即可翰撑。

????????Django其實包含了object permission的框架，但沒有具體實現(xiàn)啊央，object permission的實現(xiàn)需要借助第三方app?django-guardian眶诈，我們在開發(fā)中用調(diào)用django guradian封裝好的方法即可。

Django的權(quán)限項

????????Django用permission對象存儲權(quán)限項瓜饥，每個model默認(rèn)都有三個permission逝撬，即add model, change model和delete model。例如乓土，定義一個名為『Car』model宪潮，定義好Car之后，會自動創(chuàng)建相應(yīng)的三個permission：add_car,?change_car和delete_car趣苏。Django還允許自定義permission坎炼，例如，我們可以為Car創(chuàng)建新的權(quán)限項：drive_car,?clean_car,?fix_car等等

????????需要注意的是拦键，permission總是與model對應(yīng)的，如果一個object不是model的實例檩淋，我們無法為它創(chuàng)建/分配權(quán)限芬为。

Django 自帶權(quán)限機(jī)制的應(yīng)用

1.Permission

????????如上文所述，Django定義每個model后蟀悦，默認(rèn)都會添加該model的add, change和delete三個permission媚朦，自定義的permission可以在我們定義model時手動添加：

????????每個permission都是django.contrib.auth.Permission類型的實例，該類型包含三個字段name,?codename?和?content_type日戈，其中content_type反應(yīng)了permission屬于哪個model询张，codename如上面的view_task，代碼邏輯中檢查權(quán)限時要用浙炼，name是permission的描述份氧，將permission打印到屏幕或頁面時默認(rèn)顯示的就是name唯袄。

????????在model中創(chuàng)建自定義權(quán)限，從系統(tǒng)開發(fā)的角度蜗帜，可理解為創(chuàng)建系統(tǒng)的內(nèi)置權(quán)限恋拷，如果需求中涉及到用戶使用系統(tǒng)時創(chuàng)建自定義權(quán)限，則要通過下面方法：

2.2 User Permission管理

????????User對象的user_permission字段管理用戶的權(quán)限：

????????檢查用戶權(quán)限用has_perm()方法：

? ??????has_perm()方法的參數(shù)厅缺，即permission的codename蔬顾，但傳遞參數(shù)時需要加上model 所屬app的前綴，格式為.湘捎。無論permission賦予user還是group诀豁，has_perm()方法均適用。

? ??????user.get_all_permissions()方法列出用戶的所有權(quán)限窥妇，返回值是permission name的listuser.

? ??????get_group_permissions()方法列出用戶所屬group的權(quán)限舷胜，返回值是permission name的list

2.3 Group Permission管理

????????group permission管理邏輯與user permission管理一致，group中使用permissions字段做權(quán)限管理：

? ??????權(quán)限檢查：依然使用user.has_perm()方法秩伞。

2.4?permission_required?裝飾器

????????權(quán)限能約束用戶行為逞带，當(dāng)業(yè)務(wù)邏輯中涉及到權(quán)限檢查時，decorator能夠分離權(quán)限驗證和核心的業(yè)務(wù)邏輯纱新，使代碼更簡潔展氓，邏輯更清晰。permission的decorator為permission_required：

2.5 Template中的權(quán)限檢查

????????Template中使用全局變量perms存儲當(dāng)前用戶的所有權(quán)限脸爱，權(quán)限檢查可以參考下面例子：

基于Django-guardian的object permission的應(yīng)用

????????Django-guardian基于django的原生邏輯擴(kuò)展了django的權(quán)限機(jī)制遇汞，應(yīng)用django-guardian后，可以使用django-guardian提供的方法以及django的原生方法檢查全局權(quán)限簿废，django-guardian提供的object permission機(jī)制使django的權(quán)限機(jī)制更加完善空入。

????????django-guardian詳細(xì)的使用文檔請參考官方文檔，其object permission常用方法如下：

3.1 添加object permission

? ??????添加object permission使用assign_perm()方法族檬，如為用戶添加對mycar對象的drive_car權(quán)限：

????????assign_perm()方法也可用于group：

3.2 權(quán)限檢查

3.2.1 Global permission

? ??????get_perms()方法用于檢查用戶的“全局權(quán)限”（global permission）歪赢，與user.has_perm()異曲同工，如：

????????例子中雖然把post object作為參數(shù)傳給get_perms()方法单料，但它只檢查user的全局權(quán)限中是否有main.change_post權(quán)限埋凯，很多情況下可用原生的user.has_perm取代，但user和group均可作為get_perms()的傳入?yún)?shù)扫尖，某些情況下可以使代碼更簡潔白对。

3.2.2 Object permission

????????Django-guardian中使用ObjectPermissionChecker檢查用戶的object permission，示例如下：

3.3 permission_required裝飾器

????????guardian.decorators.permission_required是django-guardian權(quán)限檢查的decorator换怖，既可以檢查全局權(quán)限甩恼，又可以檢查對象權(quán)限（object permission），其中，accept_global_perms參數(shù)指出是否檢查user的global permission条摸，如：

注：

????????decorator中的(models.Post, 'id', 'pk')部分悦污，用于指定object實例，如果忽略這個參數(shù)屈溉，則不論accept_global_perms值為True還是False塞关，均僅僅檢查全局權(quán)限。

????????權(quán)限管理其實就是給model取了一個權(quán)限的名字子巾，具體的權(quán)限實現(xiàn)是在進(jìn)行邏輯判斷的時候根據(jù)判斷model是否具有某個權(quán)限來顯示能進(jìn)行的操作帆赢？ （權(quán)限管理=權(quán)限名稱+邏輯判斷）