數據庫表結構
用戶是屬於1~n個角色的，當然也可以設計成用戶是屬於0~n個角色的,
然後在代碼中對所有人都能做的操作不做權限判斷.
例如你去公園玩,會給你發一張門票
一種情況是上面顯示所有可玩的項目(含免費和收費).
所有項目的遊戲入口處都有人查票.
另一種情況是公園管理者只在門票上列上所有你可玩的收費項目,
沒人查票的遊戲入口處代表它是免費的(摩天輪的遊戲入口處沒有人查票)
那麼,當有一天摩天輪變爲了收費項目,第二種管理方案要做怎麼樣的改變呢?
1.摩天輪的遊戲入口處要有人把守(對應於代碼就是以前不判斷權限的地方現在要做權限控制)
2.門票上的摩天輪要顯示成可玩項目,爲收費項目(對應於代碼就是權限表插一條數據,同時將此權限添加到特定範圍的角色)
第一種的改變呢?不用做任何修改
所以對於所有人都有權限的操作分配一個默認角色的好處是:
1 可以查看普通用戶所擁有的普通權限(不必到代碼中去看沒做權限判斷的就是普通用戶可做的操作).
2 可以方便地在數據庫中將普通權限變爲高級權限.
3 可以方便地在數據庫中將高級權限變爲普通權限
4 權限判斷的邏輯統一,代碼不做任何更改就可以實現權限的變動.
用戶登陸後得到其角色和權限,存放到Session中
然後寫一個ActionFilterAttribute的繼承類,也就是一個Attribute,然後在controller的action上打上標籤,如下所示:
[PageAuthorizeFilter("C29DB2EF-69C3-4CA5-92A4-1681D068BCBB|C29DB2EF-69C3-4CA5-92A4-1681D068BCCC|C29DB2EF-69C3-4CA5-92A4-1681D068BDDD|C29DB2EF-69C3-4CA5-92A4-1681D068BEEE|D5E3B311-6E3E-4AD3-9A3C-33D6FEEA78B1|C56DC5EF-3F10-40B4-94B6-F5F5AF9424CC")]
public ActionResult Index(FormCollection collection){
}
在ActionFilterAttribute的繼承類中將SESSION中用戶角色所擁有的權限與標籤中的權限進行判斷,不滿足條件則跳轉到錯誤頁,提示權限不足.
--建登陸名，賦於其服務器角色
exec sp_addlogin web_login,'wel123!',Wicre;
exec sp_addsrvrolemember web_login,'sysadmin';
--建數據庫
drop database Wicre;
go
create database Wicre;
go
use [wicre]
go
--用戶表
CREATE TABLE UsrInfo (
UsrId int not null primary key,
UsrName varchar(20) not null,
Pwd varchar(20) not null,
Birthday datetime null default GETDATE()
)
go
CREATE TABLE RoleInfo (
RoleId int not null primary key,
RoleName varchar(20) not null
)
go
CREATE TABLE PrivilegeInfo (
PrivilegeId int not null primary key,
PrivilegeName varchar(20) not null
)
go
CREATE TABLE UsrRole (
UsrId int not null,
RoleId int not null
)
go
CREATE TABLE RolePrivilege (
RoleId int not null,
PrivilegeId int not null
)
go
alter table UsrRole add constraint fk_usrinfo
FOREIGN KEY ( UsrId )
REFERENCES USRINFO (UsrId) on delete cascade;
go
alter table RolePrivilege add constraint fk_roleinfo
FOREIGN KEY ( RoleId )
REFERENCES ROLEINFO (RoleId) on delete cascade;
go
--alter table UsrRole drop constraint fk_usrinfo;
