权限设计的探讨

凡是波及多用户各别权力的搜集大概单机步调，城市有权力处置的题目，比拟超过的是mis体例。  底下我要说的是mis体例权力处置的数据库安排及实行，固然，那些思绪也不妨实行飞来运用，比方说在bbs顶用来处置各别级其余用户权力。  权力安排常常囊括数据库安排、运用步调接口(api)安排、步调实行三个局部。  这三个局部彼此依存，密不行分，要实行完备的权力处置体制，必需商量到每一个步骤可行性与搀杂水平以至实行功效。  咱们将权力分门别类，开始是对准数据存取的权力，常常有录入、欣赏、窜改、简略四种，其次是功效，它不妨囊括比方统计等一切非径直数据存取操纵，其余，咱们还大概对少许要害数据表某些字段的存取举行控制。除此，我想不出再有其余品种的权力类型。  完备的权力安排该当具备充溢的可扩充性，也即是说，体例减少了新的其它功效不该当对所有权力处置体制带来较大的变革，要到达这个手段，开始是数据库安排有理，其次是运用步调接口典型。  咱们先计划数据库安排。常常咱们运用联系数据库，这边不计划鉴于lotus产物的权力处置。  权力表及关系实质大概不妨用六个表来刻画，如次：  1 脚色（即用户组）表：囊括三个字段，id，脚色名，对该脚色的刻画；  2 用户表：囊括三个或之上字段，id，用户名，对该用户的刻画，其它（如地方、电话等消息）；  3 脚色-用户对应表：该表记委派户与脚色之间的对应联系，一个用户不妨从属于多个脚色，一个脚色组也可具有多个用户。囊括三个字段，id，脚色id，用户id；  4 控制实质列表：该表记载一切须要加以权力辨别控制的数据表、功效和字段等实质及其刻画，囊括三个字段，id，称呼，刻画；  5 权力列表：该表记载一切要加以遏制的权力，如录入、窜改、简略、实行等，也囊括三个字段，id，称呼，刻画；  6 权力-脚色-用户对应表：普遍情景下，咱们对脚色/用户所具有的权力做如次规则，脚色具有明确命令承诺的权力，其它一致遏止，用户接受分属脚色的十足权力，在此范畴内的权力除明确命令遏止外十足承诺，范畴外权力除明确命令承诺外十足遏止。该表的安排是权力处置的中心，安排的思绪也很多，不妨说半斤八两，不许生吞活剥说那种本领好。对此，我的管见是就部分情景，找本人感触符合能处置题目的用。  先说第一种也是最简单领会的本领，安排五个字段：id，控制实质id，权力id，脚色/用户典型（布尔型字段，用来刻画一条记载记载的是脚色权力仍旧用户权力），脚色/用户id，权力典型（布尔型字段，用来刻画一条记载表白承诺仍旧遏止）  好了，有这六个表，按照表六，咱们就不妨领会某个脚色/用户究竟具有/遏止那种权力。  大概说，这么安排仍旧充满了，咱们实足实行了所须要的功效：不妨对脚色和用户辨别举行权力定制，也具备十分的可扩充性，比方说减少了新功效，咱们只须要增添一条大概几条记载就不妨，同声运用步调接口也不必变换，具备十分的可行性。然而，在步调实行的进程中，咱们创造，运用这种本领并不是格外科学，比方欣赏某个用户所具有的权力时，须要对数据库举行屡次（以至是递归）查问，极不简单。所以咱们须要想其它的方法。运用过unix体例的人们都领会，unix文献体例将对文献的操纵权力分为三种：读、写和实行，辨别用1、2、4三个代码标识，对用户同声具备读写权力的文献被记载为3，即1+2。咱们也不妨用一致的方法来处置这个题目。发端的办法是窜改权力列表，介入一个字段：标识码，比方，咱们不妨将录入权力标识为1，欣赏权力标识为2，窜改权力标识为4，简略权力标识为8，实行权力标识为16，如许，咱们经过权力累加的方法就不妨简单的将本来要分为几条记载刻画的权力放在一道了，比方，假设某用户id为1，仓库储存表对应的控制实质id为2，同声规则脚色典型为0、用户典型为1，咱们就不妨将该用户具备录入、欣赏、窜改、简略仓库储存表的权力刻画为：2,15,1,1。  真实很大略，不是吗？以至再有更偏激的方法，将控制实质列表也加上一列，设置好标识码，如许，咱们以至不妨用大略的一条记载刻画某个用户具备的对十足实质所具备的十足权力了。固然，如许做的基础是控制实质数目比拟小，否则，呵呵，2的n次方递加起来然而数目可惊，不简单领会的。  从外表上看，上述本领足以到达实行功效、简化数据库安排及实行的搀杂度这个手段，但如许做有个缺点，咱们所波及的权力列表不是彼此独力而是彼此依附的，比方说窜改权力，本来是包括欣赏权力的，比方，咱们大概不过大略的树立用户对仓库储存表存取的权力值为录入+窜改+简略（1+4+8=13),但究竟上，该用户具备(1+2+4+8=15）的权力，也即是说，在这种计划中，13=15。所以当咱们挪用api咨询某用户能否具备欣赏权力时，就必需确定该用户能否具备对该数据表的窜改权力，所以，即使不许在步调中固化权力之间的包括联系，就不许运用运用步调接口大略的做出确定。但这与咱们的手段“充溢的可扩充性”冲突。  这个题目怎样处置？我想到了其余一种树立标识码的本领，那即是运用素数。咱们无妨将录入、欣赏、窜改、简略、实行的基础标记码定于2,3,5,7,11，当遇到权力彼此包括的功夫，咱们将它的标识码设定于两个（或多个）基础标记码的乘积，比方，不妨将“窜改”功效的标记码定于3*5=15，而后将一切的权力相加，就获得了咱们须要的最后权力标识值。如许，咱们在咨询用户能否具备某项权力的功夫，只须要将最后的值领会成质因子，比方，咱们不妨设置一个用户具备录入+窜改+简略仓库储存表的权力为 2*15*7=2*3*5*7，即表白，该用户具备了对仓库储存表录入+欣赏+窜改+简略权力。  固然，对权力列表咱们运用上述本领的基础是权力列表记载条数不会太多而且联系不是格外搀杂，要不，光是领会权力代码就要呆板忽悠半宿：）  我蓄意之上的领会是精确且灵验的（究竟上，我也用那些的本领在不只一套体例中实行），但不管怎样，我感触如许实行权力处置，不过商量了数据库安排和运用步调接口两局部实质，对于实行，仍旧显得很吃力。所以，我恳请有过一致安排、实行体味的同道们提出树立性的看法和窜改倡导。  其余，对于数据库安排的思绪再有运用二维表的，这将在此后的功夫里计划，对于运用步调接口的安排和实行我也将在运用其余篇幅和大师共通商量，代码将用类c语法实行（我不爱好pascal，对不起）  欢送伙伴们和我接洽，mailto:berg@91search.com，也欢送考察我和其余一位伙伴共通树立的网站：http://www.91search.com，何处将有一个音乐探求的东西软硬件供给载入。   ======================================== 对于权力容纳联系经过脚色和权力掩码来实行。  /// <summary>  /// 权力养护典型列举典型。  /// </summary>  public enum protectenum  {   /// <summary>撤回权力养护典型</summary>   revokeprotect = 0,   /// <summary>赋予权力养护典型</summary>   grantprotect = 1,   /// <summary>中断权力养护典型</summary>   denyprotect  = 2  }[page_break]/// <summary>  /// 体例恒定用户或脚色列举典型。  /// </summary>  /// <remarks>  /// 处置员脚色：16399 = 100000000001111  /// 一切者脚色：16385 = 100000000000001  /// 只读者群脚色：16386 = 100000000000010  /// 安定员脚色：16388 = 100000000000100  /// 摆设员脚色：16392 = 100000000001000  /// </remarks>  public enum fixedroleenum  {   ///<summary>体例处置员恒定用户</summary>   administrator = 1,   ///<summary>体例处置员恒定脚色</summary>   administrators = 16399,   ///<summary>一切者恒定脚色（具备读写操纵之权力）</summary>   authors  = 16385,   ///<summary>只读者群恒定脚色（具备只读操纵之权力）</summary>   readers  = 16386,   ///<summary>体例安定处置员恒定脚色</summary>   security = 16388,   ///<summary>体例树立处置员恒定脚色</summary>   setting  = 16392  }  /// <summary>  /// 体例权力列举典型。  /// </summary>  public enum permissionenum  {   /// <summary>“读取”权力</summary>   fetchpermission = 1,   /// <summary>“新增”权力</summary>   addnewpermission = 2,   /// <summary>“革新”权力</summary>   updatepermission = 4,   /// <summary>“简略”权力</summary>   deletepermission = 8,   /// <summary>“打字与印刷”权力</summary>   printpermission = 16,   /// <summary>体例保持，运用于过程处置</summary>   flowpermission = 1024,   /// <summary>体例保持，运用于过程处置</summary>   voidpermission = 2048  } 即使用户“popeye”对“出卖出仓单[2009]”体例东西具备读写（读取＋窜改＋简略＋新增）权力：（权力表设置如次tpermission） formid       uid           permission =======      ====          ========== 2009         popeye        1+2+4+8=15 ***** 上头体例设置的默许权力确定是不够体例运用的，那么再有少许权力（比方：报警体例中的“计划分别表”“创造申诉单”等权力，就由体例再设置），本来不必太担忧会不够用的，由于在一个form中不大概会展示一切权力情景，以是，体例自设置的权力掩码可反复运用在各别的表单中。***** 倡导不要把脚色和用户划分两张表来保存（可参考ms-sql server中的sys_users表），由于在反面的权力设置表须要援用这个表的uid（其可为用户或脚色，sql中是运用uid的数值范畴来辨别用户与脚色的，倡导也如许。），版主说的脚色与用户划分周旋权力树立，这点我不扶助。由于脚色只然而是一种用户组，其该当享受用户的权力设置范畴，在其部下的脚色分子（提防脚色分子各别于用户或脚色哦，其不妨为脚色也不妨为用户）均默许接受其设置的权力，只有脚色分子从新指使其上司脚色设置的权力字。底下给出我的关系表设置： tuser(用户或脚色表) =================== (pk)uid   int              not null（主键） name      nvarchar(50)     not null（独一性牵制） fullname  nvarchar(100)    null description   nvarchar(255)  null masterno  varchar(25)     null（注：该字段对应为职工表中的职工编号，经过该字段就不妨关系领会该用户或脚色分属的职工了，在企业处置体例中很有效啊！） tmember(用户与脚色联系表) ========================= (*pk)roleid    int   not null (*pk)userid    int   not null tpermission(用户权力表) ======================= (*pk)formid    int   not null（表白体例中各个模块或表单的独一编号） (*pk)userid    int   not null（用户或脚色编号） protect        bit   not null（1：表白表露赋予权力；0：表白表露中断权力） permission     int   not null（权力掩码和） ***** 即使哪位伯仲蓄意接洽权力与过程定制上面的东东，断定找偶是没错的了！！！呵呵～～～    东家，给分啊～～～～～××××× ========================================== 之上的本领与我做的项手段本领基础普遍，现摘一局部的表构造，以供大师参考 create table t_workelement /*处事元素表*/ (  code varchar(20) not null, /*元素的代码，独一*/  name varchar(50)  not null unique,/*元素的称呼，独一*/  type int  not null, /*典型 0-单子操纵 1-报表操纵 2-功效操纵*/  bcode varchar(20) null,  /*对应操纵的单子\报表\功效的代码*/  style int  null,  /*单子：典型 0-察看 1-新增 2-窜改 3-简略*/       /*报表：无*/       /*功效：无*/  term ntext  null,  /*单子：察看\窜改\简略时要适合的前提,如"{$兜揽公约.编号}=12\n{$兜揽公约.称呼}<>’afd’"*/  primary key(code) ) go drop table t_role go create table t_role /*脚色表*/ (  name varchar(30) not null,  category varchar(50) null,  remark varchar(100) null,  primary key(name) ) go drop table t_roleelement go create table t_roleelement /*脚色元素操纵表*/ (  rname varchar(30) not null, /*脚色称呼*/  ecode varchar(20) not null, /*元素的代码*/  primary key(rname,ecode) ) go drop table t_users go create table t_users /*用户表*/ (  name varchar(20) not null, /*用户的称呼*/  dcode varchar(20) not null, /*分属的部分*/  category varchar(50) null,  /*用户的类型*/  pswd varchar(15) null,  /*暗号*/  primary key(name) ) go /*插入体例处置员*/ insert into t_users (  name,  dcode,  category,  pswd ) values (  ’admini’,  ’system’,  ’超等用户’,  ’’ ) go drop table t_userrole go create table t_userrole /*用户脚色表*/ (  uname varchar(20) not null, /*用户称呼*/  rname varchar(30) not null, /*脚色的称呼*/  primary key(uname,rname) ) go insert into t_userrole (  uname,  rname ) values (  ’admini’,  ’体例处置员’ ) go drop table t_dept go create table t_dept /*部分表*/ (  code varchar(20) not null, /*部分的代码*/  name varchar(50) not null unique,/*部分的称呼*/  type varchar(10) null,  /*部分的类型 行政 堆栈 小组*/  subtype varchar(16) null,  /*子类型 制品堆栈 材料堆栈自设置*/  primary key(code) ) go /*插入体例处置部*/ insert into t_dept (  code,  name,  type ) values (  ’system’,  ’体例处置部’,  ’行政’ ) go