Django預設許可權機制介紹及實踐
演示Django版本為當前最新版本v2.2
當Django配置檔案中的INSTALL_APPS
包含了django.contrib.auth
時,就預設啟用了一個簡單的許可權系統,提供了為使用者或組分配許可權的方法
之所以說簡單呢?主要是因為:
- 預設的許可權系統是基於表的控制,許可權最小粒度是表
也就是說,假如有一個Blog表,我們可以賦予使用者或組對Blog表有delete的許可權,那麼使用者或組成員就可以刪除全部Blog,是不能控制使用者只能刪除自己建立的blog的
如果希望使用者只能刪除自己建立的Blog,不能刪除別人建立的Blog,這種需求Django預設的許可權管理就無法實現了,需要用到object permission
- 每個Model模型預設只有四個許可權,分別是新增
add_
、修改change_
、刪除delete_
、檢視view_
,這些許可權記錄在Permission表中,表資料如下:
預設許可權的建立是通過Django的訊號signals實現的,使用了post_migrate
訊號,在每次執行migrate操作時都會為新的Model模型建立預設許可權,關於Django的訊號Signals介紹和使用可以檢視這篇文章:Django使用Signals監測model欄位變化傳送通知,
自定義許可權
預設的許可權名字和描述都是英文的,且只有四個,如果你不想用預設的幾個許可權,想要自定義的話,可以這樣做:
class Blog(models.Model): title = models.CharField(max_length=256, verbose_name='標題') content = models.TextField(blank=True, null=True, verbose_name='內容') class Meta: default_permissions = () permissions = ( ("change_blog", "修改部落格"), ("delete_blog", "檢視部落格"), ("publish_blog", "釋出部落格"), )
default_permissions: 清空預設的許可權
permissions: 設定許可權,內容是一個巢狀的列表,列表第一個欄位是codename
,第二個欄位為name
注意:如果你使用了django預設的admin的話,建議保留4個預設許可權,可以新增新許可權
許可權修改
如果你用了Django自帶的admin,在migrate之後就能在admin的user和group兩個表中看到新新增的許可權了
當然你也可以在程式中來新增或修改許可權
使用者許可權修改方法:
ops = User.objects.get(id=2)
ops.user_permissions.add(25, 26)
ops.user_permissions.set([26, 27])
ops.user_permissions.remove(26, 27)
ops.user_permissions.clear()
組許可權修改方法:
coffee = Group.objects.get(id=1)
coffee.permissions.add(25)
coffee.permissions.set([26,27])
coffee.permissions.remove(25)
coffee.permissions.clear()
其中add
為新增,set
為設定,remove
為移除,clear
為清空,add
跟set
的區別是add
會在原有許可權的基礎上加新許可權,而set
會清空原有許可權設定成新的許可權,後邊的引數25,26,27可以為Permission的ID或者是Permission物件,例如這樣也是可以的:
p = Permission.objects.get(id=25)
coffee.permissions.add(p)
給組賦予許可權,組內的所有使用者會自動的擁有該組的許可權,例如使用者ops-coffee
隸屬於組SRE
,SRE
組對Blog表有修改許可權,那麼即便是沒有單獨給Y37
使用者分配任何許可權,他也會有對Blog表的修改許可權
許可權檢視
get_all_permissions()
列出使用者的所有許可權:
>>> User.objects.get(username='ops-coffee').get_all_permissions()
{'blog.publish_blog', 'blog.delete_blog', 'auth.add_group', 'blog.change_blog'}
get_group_permissions()
列出使用者所屬組的許可權:
>>> User.objects.get(username='ops-coffee').get_group_permissions()
{'blog.publish_blog', 'blog.change_blog', 'blog.delete_blog'}
許可權校驗
使用者物件可以通過has_perm
方法來判斷使用者是否擁有某個許可權:
>>> User.objects.get(username='ops-coffee').has_perm('blog.change_blog')
True
>>> User.objects.get(username='ops-coffee').has_perm('blog.delete_blog')
True
has_perm 的引數由<app label>.<permission codename>
兩部分組成,例如blog.delete_blog
表示的就是名字為blog
的APP下的delete_blog
許可權
後端View校驗許可權
可以直接在view中通過if判斷使用者許可權,例如:
def ops_coffee_view(request):
if not request.user.has_perm('blog.change_blog')
return HttpResponse('403 Forbidden')
為了方便,Django還提供了一個permission_required()
的裝飾器,可以快速的來校驗使用者是否擁有特定的許可權,用法如下:
@permission_required(perm, login_url=None, raise_exception=False)
三個引數的意思分別是:
perm: 必須有,許可權名稱,同has_perm
一樣
login_url: 非必須,登陸的url地址,當你沒有許可權時自動跳轉到登陸頁,這裡可以設定登陸地址的url
reise_exception: 非必須,當為True時,如果使用者沒有許可權,則不會跳轉到登陸頁,而是引發PermissionDenied
錯誤,返回403 Forbidden
如下例子,判斷使用者是否有blog
的APP的change_blog
許可權,如果沒有則返回403錯誤
@permission_required('blog.change_blog', raise_exception=True)
def ops_coffee_view(request):
...
前端Template中校驗許可權
當前登陸使用者的許可權儲存在模版變數{{ perms }}
中,可以在模版中通過if判斷使用者是否擁有相應的許可權而開放對應的內容,例如對於側邊欄菜單隻顯示使用者有許可權訪問的,就可以這麼寫:
{% if perms.cmdb.view_project %}
<li><a href="{% url 'project-list-url' %}"></i> 專案列表</a></li>
{% endif %}
{% if perms.cmdb.view_service %}
<li><a href="{% url 'service-list-url' %}"></i> 服務列表</a></li>
{% endif %}
{% if perms.cmdb.view_environment %}
<li><a href="{% url 'environment-list-url' %}"></i> 環境列表</a></li>
{% endif %}
至此,Django的預設許可權系統介紹完成,預設許可權在小型專案中能滿足大部分的需求,如果對許可權控制有更高的要求可以關注前文中介紹的django-guardian
專案或自己實現
相關文章推薦閱讀:
- Django+zTree構建組織架構樹
- 利用Django徒手寫個靜態頁面生成工具