权限管理可插拔的问题
 |
metadmin
2009-04-21
就权限可插拔方案，我这里抛出2个问题，想征求大家的建议。
1，哪些地方需要进行权限验证？验证功能权限呢，还是需要深入验证数据级权限？ 2，最佳可插拔方案是什么？配置or...？ 我先谈谈我的看法： 1，哪些地方需要权限验证。 a，需要权限验证的地方，应该是url。bean-method不应该是。因为：需要进行权限验证的，是客户需求，而不是编程设计需求。在设计类、方法的时候，开发人员不需要考虑哪些方法由哪些角色访问。 客户在考虑权限的时候，肯定是功能。功能就应该对应着一个功能入口点。对于web系统，这个入口点肯定是url。 b，如果能深入验证数据级权限，那肯定再好不过啦。如果不行，就控制到功能级（验证角色）。 但，请不要引入一大堆XML配置文件。 因为：引入很多XML配置文件，还不如写个API调用。 2，我想到的就是filter。 但， 还是拒绝n多配置文件，或者n多配置表。要不维护xml配置文件，要不维护配置表，都是我不可接受的。 欢迎大家，谈谈您的看法。 |
 |
chiron.k
2009-04-23
这个还要看应用类型吧，如果应用是基于操作的，比如点击链接，提交，触发的都是一个方法，我觉的验证权限加在METHOD的上是没问题的，比如现在很多AJAX RPC的调用，如果加在URL上，也没有办法做权限认证
|
 |
jaroddang
2009-04-23
要我说用户服务(包括权限服务),就应该和ESB集成在一起。
|
|
jaroddang
2009-04-23
你的看法是有很强的前提条件的，那就是B/S
这点很难实现，现在哪个企业没有一两个C/S的信息系统，很难吧 我感觉大家的困境有下面几点 1.被动，凡是要上这种系统的，都是已经有了N多在运行，而且是运行多年的业务系统的企业 2.改造，接着上面说，业务系统已经很难去改造以适应现在的需求了，只能咱们适应人家 3.用户接受度和上线的风险，用户对权限管理系统不够了解和理解，并且大范围配合改造风险太大，所以我们只能一步一步来，等二期？真不一定是猴年马月了 我倒是觉得做一个网关型的硬件产品用户倒是更容易接受，只是说说，确实没有太深入想过 |
|
metadmin
2009-04-23
对，最好就是搞个类似 网关的东东。 以前的代码都可以不用改， 直接插上“权限管理”即不影响原有系统运行， 还可以保证这些系统正常运行。
对，我前面的说法，局限于B/S结构了。不过“访问点”说法，也可以拓展到C/S结构。 下面，举个例子： CustomerDao.addCustomer(Customer customer) 这个dao向数据库添加Customer记录； CustomerServlet（为web服务的）或者CustomerService（为Application服务的），都含有这样的代码： User currentUser=...; Customer toAddCustomer=...; customerDao.addCustomer( toAddCustomer ); 那么，这里访问点是什么呢？我们怎么区分？ |
|
metadmin
2009-04-23
或者说访问点，这种说法不对。
|
|
jaroddang
2009-04-24
我觉得在service层比较合适，就是调用customerDao.addCustomer( toAddCustomer )之前
service->网管->dao 因为业务逻辑在service层做处理，到了dao理论上就与业务无关了 |
|
metadmin
2009-04-24
OK， 现在有2个问题需要解决：
1， 网管， 何时被自动触发？ 应该在dao.addCustomer方法执行前被触发吗？ 2， 网管， 怎么获取到当前用户呢？ toAddCustomer倒是可以在addCustomer的参数里面获取。。。 不过这点， 也有局限性， 假设toAddCustomer有两个输入参数怎么办？ |
|
jaroddang
2009-04-24
最近接触到一种新的方式，让我有了这方面的想像。
现在很多网管产品可以结合AD,判断用户是否可以访问某些应用，网站 无论C/S还是B/S，你总是客户端去连服务端吧，就是在你Client和Server交互的过程中，做权限处理 |
 |
wei_jing
2009-04-26
aop正好适合做网关
|
