关于权限管理一些想法，还请各位高手GGJJ们指点指点。

Question

樓主的想法是可以的：補充一點想法：
1、在user表裡增加角色ID，（如果有多個可考慮增代理表）
2、在權限表裡指定每一個角色對應與每個表的權限和限制條件
3、在前台進行數據操作時將權限表中對應角色的限制條件抓出做為Where子句

Answer 1

基于用户、角色、权限的概念可以彻底解决以上问题.权限：用户对一个功能点能做的操作，包括对一个页面的打开，对一个业务逻辑的调用；用户：用户名/口令字构成的一对；角色：权限的集合。相互之间的对应关系：用户和权限之间没有直接对应关系；一个用户可以扮演多个角色，多个用户可以扮演相同的角色；一个角色对应了由若干个权限组成的集合，某个权限可以分属多个不同的角色。
把以上三个概念实现在你的数据库中作为应用的基础。在使用的时候，应该让所有的用户通过同一个登录页面登录；
登录页面对用户的口令字/用户名进行验证，如果合法的话在Session对象的集合里面写上他（她）的角色；
在使用任何一个功能点之前验证用户的权限是否足够，从Session对象里面获取他（她）的角色，从数据库里面查看他（她）是否有足够的权限。以上就是解决类似问题的通用解决办法。
如果你的用户使用USB Encripted Token之类的加密工具，他（她）的角色就可以写在他的USB Token里面，那样子的话就更安全。
-----------------
前提：
1、登录者是已经注册的用户
2、有设置权限范围（即是将被管理的对象）   
      如： 公司的每个部门，系统的每个模块，每级栏目等。设置：
1、被管理对象，
         按类设置被管理对象的值（唯一性），类别中再设小类。
        如，集团为1，集团下公司为01，集团下工厂为02
            公司财务部相对应的唯一值为： 01001；公司技术部的值为：01002
            工厂财务部相对应的唯一值为： 02001；工厂营销部的值为：020022、管理者
         给管理者赋权限：想给他管理公司财务部，在该用户的相关字段Rank（假设）写入01001；如果同时管理公司财务部和公司技术部那么Rank为01001，01002（多选）；多个权限类推。 如果管理整个公司则Rank为013、判别权限时，用户Rank字段与被管理对象的相对应的字段进行比较。。----------------
基于用户、角色、权限的概念可以彻底解决以上问题.
这个太对了！
权限：用户对一个功能点能做的操作，包括对一个页面的打开，对一个业务逻辑的调用；一般分为这么几种 浏览 查询（对select的划分） 增加  修改（这个包括审定）删除  还有一个级别。用户：用户名/口令字构成的一对；
通常情况下要做到这么复杂的系统口令和用户名最好都加密 :) 
口令最好是 不可逆加密 用户就不能:)
角色：权限的集合。
这里假定有级别 （可以为一数组） 和其它的权限 浏览查询另外业务跟角色的关系有两种写法  1、由业务上定义某个角色
                              2、角色对某个业务的处理
上面两个方法大致一样，但是我认为采用1、更好。因为以后业务的变化是经常的。
在使用的时候，应该让所有的用户通过同一个登录页面登录；
登录页面对用户的口令字/用户名进行验证，如果合法的话在Session对象的集合里面写上他（她）的角色；
在使用任何一个功能点之前验证用户的权限是否足够，从Session对象里面获取他（她）的角色，从数据库里面查看他（她）是否有足够的权限。-------------------------
用户/权限系统：
几个基本概念：
1.元权限：最基本的权限元素。如添加、修改、删除、审核等都属于一个元权限。
2.权限范围：一个行使权限的空间范围和时间范围。比如只在asp论坛内有修改权限，在delphi论坛却没有，同时必须指定在asp论坛内行使权力的时限。
3.角色：角色= 一组元权限 ＋ 权限范围
4.用户：用户名/口令字构成对。
5.用户组：具有相同权限的用户可以划为一个组。
6.授权：对某个用户/用户组赋某个角色。
7.用户转组：将用户转到其他用户组中。

Answer 2

你做的不错，一般中小型软件都是这种做法。to TaoGeGe(涛哥哥)
1、在user表裡增加角色ID，（如果有多個可考慮增代理表）re: 他的管理表就是你说的代理表。2、在權限表裡指定每一個角色對應與每個表的權限和限制條件re: 这个没有必要，应为一个模块，一个对象，一个主表有许多对应的子表，辅助编码表，有时一个对象由几个表组成。3、在前台進行數據操作時將權限表中對應角色的限制條件抓出做為Where子句re: 这个要看楼主的功力了，这是前台实现技巧。

Answer 3

我现在还有一个问题，是不是要为每个用户建立一个连接数据库的用户帐号的。我的想法是
先用一个默认的帐号（只能读取user表）读出用户的帐号名和密码，如果通过验证则从用户所读出的帐号进行登陆，将关于此用户的所有权限的数据一次读入session[]中。每当用户对一页面执行打开操作时，就对其进行判断。如果这样的话，好象是每个用户都会有一个登陆数据库的帐号，这样会不会不太合适呢？大家是用什么方法让用户连接数据库并且把用户帐号如何和登陆帐号相关联的呢。。

Answer 4

我现在还有一个问题，是不是要为每个用户建立一个连接数据库的用户帐号的。
你可以是为每个用户建立一个连接数据库的用户帐号，在分配到不同的ROLE中，比如DB_RW,DB_RN,DB_ADMIN.也可以只建立几个固定的LOGIN.每当用户对一页面执行打开操作时，就对其进行判断。如果这样的话，好象是每个用户都会有一个登陆数据库的帐号，这样会不会不太合适呢？
你可以配置一个只读的权限的USER,读取权限表中配置用户的权限，比如你可以先一DB_RW的USER login,然后读取用户的权限（可以生成一个XML文件，也可已是一个加密的字符串），这样在USER要访问一些资源是就可以读取该XML文件。要主要在MSSQLSERVER中LOGIN和USER是不同的概念。用户帐号必须和登陆帐号相关联才有作用。

Answer 5

请问CrazyFor(蚂蚁) 兄，跳过角色有什么好处吗以及如何跳过角色呢？

Answer 6

接上贴：========================================关于权限包容关系通过角色和权限掩码来实现。 /// <summary>
 /// 权限保护类型枚举类型。
 /// </summary>
 public enum ProtectEnum
 {
  /// <summary>撤回权限保护类型</summary>
  RevokeProtect = 0,
  /// <summary>授予权限保护类型</summary>
  GrantProtect = 1,
  /// <summary>拒绝权限保护类型</summary>
  DenyProtect  = 2
 } /// <summary>
 /// 系统固定用户或角色枚举类型。
 /// </summary>
 /// <res>
 /// 管理员角色：16399 = 100000000001111
 /// 所有者角色：16385 = 100000000000001
 /// 只读者角色：16386 = 100000000000010
 /// 安全员角色：16388 = 100000000000100
 /// 配置员角色：16392 = 100000000001000
 /// </res>
 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 NULLTPermission(用户权限表)
=======================
(*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,
 re 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

Answer 7

我在实际做的过程中发现系统给的存储过程好象不能放在事务里面和触发器中。请问如何解决这个问题呢？不然的话，可能会出现错误。比如sp_adduser等关于安全管理方面的存储过程。

Answer 8

TO:    pengdali(大力 V2.0) ( ) 信誉：534  2003-08-23 15:08:00  2、在權限表裡指定每一個角色對應與每個表的權限和限制條件re: 这个没有必要，应为一个模块，一个对象，一个主表有许多对应的子表，辅助编码表，有时一个对象由几个表组成。
------------------------------------------------------------我對"老兄對我的回復的解析"1、3都沒有異議，對2需要進一步表達一下我的想法：我是這樣想的：1、對一個表的控制，可以達到字段級的控制，比如在查詢數據時我們可以隻允許未被授權的用戶查詢"date<'1999-1-1'"等等，可以體現在一個字段的限制條件上2、一個主表對應的每個子表，從它的形成和使用來看，她也是獨立的（這也是其存在的原因），我們也是可以對他的主要字段加以控制的。她於主表的相互關系，要放在表與表間的約束及程序中的相互查詢約束來體現這就是為什麼要對每個表及字段都設限制條件，上次沒有很清楚的描述，這次請指導。

Answer 9

我在实际做的过程中发现系统给的存储过程好象不能放在事务里面和触发器中。请问如何解决这个问题呢？不然的话，可能会出现错误。比如sp_adduser等关于安全管理方面的存储过程。不会的，你自定义的SP肯定可以调用系统的存储过程！！

Answer 10

“WINDOWS2000用户的权限”和NTFS分区下“目录及文件访问控制”（ACL）权限怎么设计实现的？