rbac是基於角色的訪問控制（role-based access control ）在rbac中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。
這就極大地簡化了許可權的管理。這樣管理都是層級相互依賴的，許可權賦予給角色，而把角色又賦予使用者，這樣的許可權設計很清楚，管理起來很方便。
rbac一般都是公司內部進行使用，如財務部成員擁有檢視財務報表的許可權，人事部的成員擁有檢視近期公司人員入職離職情況的許可權等。
在前台中，也就是面向使用者的資源中主要有三大許可權，如下：
認證（是否登入）而在後台中，也就是面向公司內部的人員擁有哪些許可權。許可權（是否能檢視到該資源）
頻率（請求是否過於頻繁）
就通過rbac來進行管理。
普通員工（只有檢視某一張表、某一條記錄的許可權）最基本的許可權管理其實三張表就夠了，如下所示：小組長（能修改，能新增）
大boss（對任何表都具有增刪改查的許可權）
每個使用者所屬不同部門，那麼不同部門擁有哪些許可權則這些使用者就具有哪些許可權，這是非常廣泛的。
但是三張表侷限性太過強烈，比如jerry不屬於助教部，它也想獲取輔導的許可權該怎麼做呢（管理人員也可以來進行輔導呀）？所以這個時候三表許可權就顯得捉襟見肘。
django中所使用的是六表許可權，（基本上五表許可權就夠了），它包含了使用者與組的關係，使用者與許可權的關係（很重要），以及組與許可權的關係。
那麼有六張表時，就可以通過修改使用者與許可權關係表來讓jerry達到具有輔導的許可權，但是jerry並不會屬於助教部，也就是額外的部門之外的許可權。
這麼說可能有點抽象，舉乙個更加形象的例子，如公司老闆不屬於任何部門，那麼他理應來說應該具有該公司所有許可權，所以三表不夠用，至少要五表才ok。
其實對於前台和後台使用者來說，一般要分為兩張表。
比如前台的是該站使用者，後台是該站管理人員。』
在django中，它只用了一張表，當然這也是可行的，我們來看一下admin中對超級管理員對於普通使用者的管理
可以看見，django會將前台和後台的使用者統一存放至auth_user表中，同時用字段來區分到底是前台還是後台使用者。
如果是後台使用者，則才能夠分配許可權，當然django提供的許可權分配相對來說還是比較粗糙的，對於許可權的區分甚至可以精確某一字段或記錄。
這裡不再過多闡述。
this簡單認識
this 在函式中簡單的說，this的指向存在於函式呼叫的時候決定的，誰呼叫了這函式 函式中的this就指向誰 例如 1 普通的呼叫函式的時候 fn window2 物件呼叫 var obj obj.f fn obj.f this obj3 定時器呼叫 因為fn不是我們自己手寫 呼叫的 底層是win...
許可權管理 RBAC簡單實現
角色表 class role models.model name models.charfield 角色名稱 max length 32,unique true class meta db table tb role abstractuser是django使用者元件裡的使用者模型類，繼承以後對原來的...
許可權管理 RBAC簡單實現
from django.db import models from django.contrib.auth.models import abstractuser from utils.mybasemodel import base create your models here.角色表 class ...