|
|
|
<p >直入正题，本文只谈思路，不谈具体代码及实现。<p >后台的权限控制大概分为两类：<p >1. 我能干什么<p >2. 我能干哪些<p >我能干什么，决定了我能做的操作是什么；我能干哪些，决定着在我有权做的情况下，我能对哪些对象进行操作。<p >俗点的意思：你可以吃饭，但你不可以吃你旁边小朋友的，（这种情况是两类权限的交集）<p >分别阐述：<p ><b>1. 能干什么</b><p >在Web开发中，和服务器交互无非是 Post/Get 方法，以Get方法为例，我们在开发一个后台应用的时候，往往一个操作，就是一个URL(地址)。例子：PicManage?action=del&id=3,5,9 。 其实Post方法也一样，只不过url里看不见而已。<p >一个人有没有这个操作权限，实际上就是看他有没有访问这个地址的权限。<p >特定地址+特定参数 = 干什么<p >在.net里所有都是请求，参数是包含在请求当中的，那就是 请求 = 干什么<p >于是，按照这种思路，我们需要一个数据表，来专门保存：后台所有的操作和对应参数<p >我们可以称之为 [行为注册表]<p >例： 操作名称： 删除图片<p > 请求页面/参数： p=picManage && action=del<p > 有此权限的用户： 5,8,12,18 (管理员ID列表)<p > 有此权限的组： 1,4,5 (组ID列表)<p > [其它必要字段.....]：....<p >在行为注册表里注册过的所有操作行为，都受到权限检测程序的控制。<p >权限检测程序要在所有业务代码运行之前运行。换言之，所有业务代码前，都要调用此程序。<p >在验证的时候，将[行为注册表] 里注册的行为，与用户提交的 请求(访问地址/参数) 进行比对，当有匹配项的时候，再去看这个用户和他所在的组，有没有权限，于是就..........。 当用户提交的请求(访问地址/参数) 在 [行为注册表] 里没有注匹配项，或者说没有注册，那就是 [未知行为] ，可根据实际开发需求，中断或放行。<p >这样做有几个好处，<p >1.开发后台应用的时候，可以暂不去考虑权限问题，等开完测试完成后，再将特定行为加到[行为注册表]中，不会影响应用的开发思路；<p >2.所有操作行为，集中保存，集中管理，集中验证；<p >3. 根据实际需求的不同，可以配置出任意粒度的操作权限，可粗可细，咋整都行，且不用修改任何业务代码；<p >由此，“能干什么”问题解决<p ><b>2. 能干哪些</b><p >这块的实现，就必须要在业务代码里控制了（“1.能做什么” 的权限控制，是不需要修改业务代码的）<p >为什么呢？： 你可以吃饭(已解决)，但你不可以吃你旁边小朋友的 ，于是每份餐上要有所属人的标识，这就必须深入到业务中了。<p > 就是说，所操作的对象或数据，要有所属人的标识，才能实现。<p >于是，设计数据表时，例：<p >[客户登记表：由销售人员录入，销售人员只能看到自己的客户资料（防止抢单），销售主管可以看到所有的客户资料]<p >ID 姓名 详细资料 销售人员(录入人)ID<p >用登录的销售人员ID，与录入人ID进行比对，就可实现 ：销售人员只能看到自己的客户资料<p >要实现：销售主管可以看到所有的客户资料 ，就需要引用一个级别的概念<p >我们可以之为 [角色级别]<p >实现起来也不复杂，可以采用一个无限级分类的结构，实现级别关系。<p >这个逻辑是成立的，代码实现就很容易了，不说了。<p >验证的时候，由登录人员的ID，找到他所在角色级别以下所有人员的ID，就可以对实现上述的需求了。<p >例：select xxx from Client where 录入人ID in (他和他所在角色级别以下所有人员的ID)<p >这就成了！！！<p >通过以上两类权限 (能干什么/能干哪些) 进行交集控制(同时使用) 即可。 <p >由此，需求解决!!!<p ><p align="right"></P><p align="center"></p></p> |
|
简体中文
英语
日语
韩语
法语
西班牙语
越南语
泰语
阿拉伯语
俄语
葡萄牙语
德语
意大利语
希腊语
荷兰语
波兰语
保加利亚语
爱沙尼亚语
丹麦语
芬兰语
捷克语
罗马尼亚语
斯洛文尼亚语
瑞典语
匈牙利语
繁体中文
文言文
发表于 2010-2-25 10:52:33
置顶卡
喧嚣卡
变色卡
千斤顶
发表于 2018-11-11 18:06:29
