django(權限、認證)系統——第三方組件實現Object級別權限控制

在我的系列blog《Django中內置的權限控制》中明確提及到，Django默認並沒有提供對Object級別的權限控制，而只是在架構上留了口子。在這篇blog中，我們探討一個簡單流行的Django組件django-guardian來實現Object level permission。

安裝配置django-guardian

首先需要安裝django-guardian,一般我們喜歡用virtualenv創建一個虛擬環境：

>>virtualenv  - - distribute venv

>>source venv / bin / activate

>>pip install Django

>>pip install django - guardian

　這樣，我們需要的django-guardian 就安裝好了。

接下來我們需要讓Django知道它，在INSTALLED_APPS變量中加入guardian:

INSTALLED_APPS  =  (

     'guardian' ,

)

然后，如果仔細讀過《Django中內置的權限控制》的第五篇文章的讀者，應該猜到，我們需要添加一個backend到AUTHENTICATION_BACKENDS中，這樣django才會具有對對象的權限控制：

AUTHENTICATION_BACKENDS  =  (

     'django.contrib.auth.backends.ModelBackend' ,  # django默認的backend

     'guardian.backends.ObjectPermissionBackend' ,

)

在guardian中，還支持對匿名用戶AnoymousUser的Object級別的權限控制，這種需求很常見，比方說允許匿名發言的論壇或者blog系統。要做到這一點需要在settings中加入：

ANONYMOUS_USER_ID = - 1

接下來我們執行python manage syncdb.執行完畢之后，系統將會創建一個User實例，叫做AnonymouseUser。

完成了以上幾點，guardian就被安裝好了，可以開始使用了。

 設置和使用對象權限：

首先當然是設置和使用對象權限了，guardian提供了一個簡單的方法：

guardian.shortcuts.assign(perm, user_or_group, obj=None)，這個方法接受3個參數：

1. perm,這個參數是一個字符串，代表一個許可，格式必須為<app>.<perm_codename>或者<perm_codename>。但是如果第三個參數是None，則必須為<app>.<perm_codename>格式。因此建議還是統一使用<app>.<perm_codename>格式。注意app並不是app的全路徑，而是最后一級的模塊名。這一點和INSTALL_APP中的app全路徑不同，如果你的app module不只一級的話，這地方一定要注意。
2. user_or_group，這個參數是一個User或者Group類型的對象。
3. obj，這個參數就是相關的對象了。改參數是可省略的，如果省略則賦予Model權限。

通過這個方法我們可以很方便通過傳入一個<app>.<perm_codename>格式的字符串來給用戶User或組Group賦予權限了。如果不傳入第三個參數，則可以當作User.user_permissions.add(permissioninstance) 的快捷方式。

下面是賦予模型級別的權限：

from  guardian.shortcuts  import  assign

user  =  User.objects.create(username = 'liuyong' )

assign( 'app.view_task' , user)

user.has_perm( 'app.view_task' ) >> True

注意，一旦賦予模型級的權限，那么所有該模型的對象級別的權限就都有了，所以應該先從對象級別進行設置，清空剛剛分配的權限然后再設置對象權限：

user  =  User.objects.get(username = 'liuyong' )

user.user_permissions.clear()

task  =  Task.objects.create(summary = 'Some job' , content = '')

assign( 'app.view_task' , user, task)

user  =  User.objects.get(username = 'liuyong' ) #刷新緩存

user.has_perm( 'app.view_task' ,task)

>> True

user.has_perm( 'app.view_task' ) #模型級別的權限還沒有

>> False

我們也可以通過設置group來使用戶具有相應的權限：

>>> group  =  Group.objects.create(name = 'employees' )

>>> assign( 'change_task' , group, task)

>>> user.has_perm( 'change_task' , task)

False

>>>  # user還不是employees組的成員,我們加入一下

>>> user.groups.add(group)

>>> user.has_perm( 'change_task' , task)

True

接下來是刪除某個用戶對某個對象的某種許可，我們需要使用guardian.shortcuts模塊中的remove_perm()函數。這個函數的簽名和assign相同，都是三個:

guardian.shortcuts.remove_perm(perm,user_or_group=None, obj=None)

樣例代碼：

>>>  from  guardian.shortcuts  import  remove_perm

>>> remove_perm( 'change_site' , user, site)

>>> user  =  User.objects.get(username = 'joe' )  #刷新user對象緩存

>>> joe.has_perm( 'change_site' , site)

False

　　

 好上面就是guadian的安裝配置和基本使用方法，下面介紹在Django的View中所能使用的一些helper函數。

Guardian在View中的使用

除了Django的user.has_perm方法之外，guardian提供了一些幫助函數能讓我們生活的更輕松。

guardian.shortcuts.get_perms(user_or_group,obj)

該方法返回user對象對obj對象所有的權限。這個行數接受兩個參數，一個是user對象或者組對象，一個是相關的對象。

比如我們可以用：

'permcodename' in get_perms(group,obj)來判斷該組是否有這個權限，因為group沒有has_perm方法。

guardian.shortcuts.get_objects_for_user(user, perms, klass=None, use_groups=True, any_perm=False)

該函數獲得該用戶下指定perm列表中的所有對象。比如我要獲得某一個用戶，擁有編輯權限的所有帖子。

get_objects_for_user(user, 'app.change_post' )

>>所有可編輯的帖子

guadian.core.ObjectPermissionChecker

該方法是一個用來判斷權限的包裝器，針對user和group提供權限相關的訪問方法，主要有has_perm(perm,obj)和get_perms(obj)兩個方法。並且提供緩存機制，在多次查找權限的時候，可以使用它。

>>> epser  =  User.objects.get(username = 'esper' )

>>> site  =  Site.objects.get_current()

>>>  from  guardian.core  import  ObjectPermissionChecker

>>> checker  =  ObjectPermissionChecker(esper)  # 我們也可以傳入組group對象

>>> checker.has_perm( 'change_site' , site)

True

>>> checker.has_perm( 'add_site' , site)  # 這次將不會產生數據庫查詢

False

>>> checker.get_perms(site)

[u 'change_site' ]

使用view的decorator

我們可以使用decorator來減少我們的代碼：

下面的代碼，演示了通過decorator控制一個view函數的訪問。我們要做到的是，只有擁有對name=foobars的Group對象擁有auth.change_group權限的用戶，才能夠執行這個view函數，否則返回的將是狀態碼為403的Response對象。

>>> joe  =  User.objects.get(username = 'joe' )

>>> foobars  =  Group.objects.create(name = 'foobars' )

>>>

>>>  from  guardian.decorators  import  permission_required_or_403

>>>  from  django.http  import  HttpResponse

>>>

>>> @permission_required_or_403( 'auth.change_group' ,

>>>     (Group,  'name' ,  'group_name' ))

>>>  def  edit_group(request, group_name):

>>>      return  HttpResponse( 'some form' )

>>>

>>>  from  django.http  import  HttpRequest

>>> request  =  HttpRequest()

>>> request.user  =  joe

>>> edit_group(request, group_name = 'foobars' )

<django.http.HttpResponseForbidden  object  at  0x102b43dd0 >

>>>

>>> joe.groups.add(foobars)

>>> edit_group(request, group_name = 'foobars' )

<django.http.HttpResponseForbidden  object  at  0x102b43e50 >

>>>

>>>  from  guardian.shortcuts  import  assign

>>> assign( 'auth.change_group' , joe, foobars)

<UserObjectPermission: foobars | joe | change_group>

>>>

>>> edit_group(request, group_name = 'foobars' )

<django.http.HttpResponse  object  at  0x102b8c8d0 >

>>>  # 這時，我們已經分配了權限，因此我們的view方法得以順利訪問了。

Guardian在模版中的使用 

 和Django一樣，我們也需要在界面上進行權限控制以顯示不同的界面。

Guardian提供了標簽:

get_obj_perms

需要加載guardian_tags標簽庫，在需要使用guardian標簽的模版上面，將其引用近來：

{ %  load guardian_tags  % }

標簽格式為：

{ %  get_obj_perms user / group  for  obj as  "context_var"  % }

例子代碼如下：

{ %  get_obj_perms request.user  for  flatpage as  "flatpage_perms"  % }

 

{ %  if  "delete_flatpage"  in  flatpage_perms  % }

     <a href = "/pages/delete?target={{ flatpage.url }}" >Remove page< / a>

{ %  endif  % }

 

下面探討一下稍微復雜一些的情況，關於孤兒對象許可（Orphaned object permissions）:

 孤兒對象許可

所謂孤兒許可，就是沒用的許可。在大多數情況下，可能沒啥事兒，但是一旦發生，后果有可能非常嚴重。

Guardian用來紀錄某用戶對某個模型對象有某個權限的紀錄時是使用UserObjectPermission和GroupObjectPermission對象紀錄的。其中對於object的引用是contenttype對象（標示是那個模型類）和pk主鍵，對於用戶則是對User表的外鍵引用。

比方說，有一個對象A。我們通過權限設置，設定joe用戶對該對象有着編輯權限。忽然有一天，用戶joe被刪除了。可想而知，我們分配而產生的UserObjectPermission對象仍然在數據庫里面，記錄着：joe 有對A的編輯權限。又有一天，一個用戶注冊了一個用戶，用戶username為joe。因為之前的那個紀錄，joe用戶擁有對A的編輯權限。而此joe非彼joe，我們犯了一個大錯誤！

再比如說，當我們刪除了某一個對象的時候，而這個對象的某種權限已經被賦予給某個用戶，那么這個權限的紀錄也就失效了。如果什么時候和曾經刪除過的對象是同一個模型類，而且主鍵和以前的那個相同，那么用戶也就有可能對其本不應該擁有權限的對象有了權限。呵呵，說起來有點繞，但是應該很容易理解。

因此，當我們刪除User和相關的Object的時候，我們一定要刪除其相關的所有UserObjectPermission和GroupObjectPermission對象。

要解決這個辦法有三個辦法，一個是顯式編碼，一個是通過其提供的自定義django命令：

$ python manage.py clean_orphan_obj_perms

Removed  11  object  permission entries with no targets

還有一個是定期調用guardian.utils.clean_orphan_obj_perms()

該函數會返回刪除的對象數目。在python的世界中，我們可以使用celery定期調度這個任務。

但是自定義命令和定期調度都不是合理的生產環境的解決辦法。要想真正解決，還是需要手動編碼實現，最優雅的方式還是加上post_delete signal給User或Object對象，關於對象的樣例代碼如下：

from  django.contrib.auth.models  import  User

from  django.contrib.contenttypes.models  import  ContentType

from  django.db.models  import  Q

from  django.db.models.signals  import  pre_delete

from  guardian.models  import  UserObjectPermission

from  guardian.models  import  GroupObjectPermission

from  school.models  import  StudyGroup

 

 

def  remove_obj_perms_connected_with_user(sender, instance,  * * kwargs):

     filters  =  Q(content_type = ContentType.objects.get_for_model(instance),

         object_pk = instance.pk)

     UserObjectPermission.objects. filter (filters).delete()

     GroupObjectPermission.objects. filter (filters).delete()

 

pre_delete.connect(remove_obj_perms_connected_with_user, sender = StudyGroup)

這樣就搞定了，不過需要寫一些必要的代碼。