用一个简单的B2C的网上商场来说,分了3个子系统实现的。
1)前台购物网站:实现用户在网站上购买商品的动作,与用户的交互部分。
2)后台配置管理网站:实现网站后台的商品管理、价格管理、订单管理等等管理配置功能部分。
3)系统配置管理工具:信息系统管理员用的,用来配置整个系统的权限配置,参数配置、数据字典管理功能部分。
这里会有这样的需求产生:
一个普通的网站客户:他只能登录前台网站,但是不能登录后台管理、系统配置管理工具,虽然用户密码都是对的,也是整个系统的有效用户,但是不允许登录后面的2个系统。
公司的一个职员(员工):他可以登录后后台配置管理网站,同样他也可以购买自己公司的商品也可以登录前台购物网站,当然没必要搞2个账户吧,就用一套用户名、密码就可以了,但是这个员工未必可以登录系统配置管理工具。
公司的信息主管:他允许登录任何系统,当然也允许信息主管购买自己公司的商品,当然也用一个账户就可以了,没必要搞3个账户出来,可以充分体现一下我们的设计水平。
解决问题:
1:前台购物网站:只要用户名、密码对了,账户没挂失、没被锁定的,都可以登录,说白了,是用户就可以登录了。
2:后台配置管理网站:不仅仅是用户名、密码要对,还需要有权限"Shopping.Admin.Access"权限才可以,登录时需要判断。
3:系统配置管理工具:不仅仅是用户名、密码要对,还需要有权限"DotNet.Admin.Access"权限才可以,登录时需要判断。
当然我们在底层有封装好的函数提供了,调用一下基于SOA服务理念的的功能函数
// 用户是否有哪个相应的权限
isAuthorized = ServiceManager.Instance.PermissionService.IsAuthorized(userInfo, permissionCode);
就可以了,其中permissionCode 为例如 "Shopping.Admin.Access"、"DotNet.Admin.Access" 就可以了。
用简单的思想解决复杂的的问题是关键、而不是用复杂的思想解决简单的问题。
权限配置的参考页面为:
权限分配的参考页面为:
用户角色的关联,给角色配置权限的参考页面为:
有灵活的配置功能,那就那些角色可以访问哪些系统,哪些用户又归属那些角色,哪些用户又可以访问哪些系统等等,都可以通过配置就可以可以达到目的了,不用修改程序源码,随时随着客户的需求变化,随时可以进行配置,很灵活,能经得起客户的折腾、需求的不断变化。
有个设计得充分严谨、可以按自己的需求灵活配置管理,想怎么管理就怎么管理,想怎么设计就怎么设计的管理工具,还是没那么容易的,经得起考验的工具,才有重复利用的价值。