Delphi 是否有相当于 Java 的 PermissionManager 或 AccessController 类?
是否有任何类(免费、开源或商业)执行类似于 Java 的访问控制 AccessController 会吗?我想创建一组可以在运行时更改的动态策略。
但是,我想避免到处编码
if Allowed( ... ) then
。我知道我可能需要调整我的程序类层次结构,但我更喜欢这样做,而不是在各处手动添加防护。
如果没有现成的代码,明智的方法是什么?实时时间间隔?
编辑:以下是 GlassFish 中的安全注释和授权的示例以及 Java EE 5 SDK 文章。由于有人在评论中提到了注释,我认为这将是理想的:
@Stateless
@RolesAllowed("javaee")
public class HelloEJB implements Hello {
@PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
来自文章:
在此示例中,每个人都可以访问 hello() 方法,而 javaee 角色的用户可以访问 bye() 方法。
编辑: 嗯,看来普遍的共识是这不能在 Delphi 中完成。其他人则认为这是一个糟糕的做法。
我,我仍然认为这会很棒。我对 Java 注释的体验(作为图腾柱中的代码猴子)是积极的。添加一个新方法,添加某种形式的注释(与 Java 安全注释不完全相同),然后就完成了。管理员稍后可以转到管理面板,并向组或个人用户添加对此新处理程序的授予访问权限。它就是有效的。
这些是我当前的替代方案:
- TMS 安全系统 - 这看起来像是一个完整的解决方案,几个工具。值得研究一下。我接受这个作为答案,即使我可能不会这么做。
- 这看起来很有前途:Delphi 虚拟方法拦截。它仅适用于虚拟方法,但我认为这并不太难遵守。这个和注释可以创建一个有趣的系统(看起来这最初是为 DataSnap 身份验证设计的)
- 在您的应用程序中只有一个 ActionManager,并确保所有操作只能从那里启动。这样你就可以使用动作管理器的
OnExecute
方法;我假装使用 TAction.Name 属性作为权限名称(“处理程序”),从表中读取允许的操作列表。我可以使用操作管理器中的操作列表在管理 UI 中显示整个列表。
Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
@Stateless
@RolesAllowed("javaee")
public class HelloEJB implements Hello {
@PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
- The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
- This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
- Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager
OnExecute
method; I pretend to use theTAction.Name
property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Delphi 还没有这样的框架,也没有像 EJB 这样适合它的概念。 DELPHI 确实支持类注释,并且可以设计这样的框架,也许与 TAction 结合使用,以提供操作级别的安全性,但我怀疑这是否可以扩展到阻止特定的方法调用。 Delphi 代码从不请求调用虚拟方法的权限。任何将自身注入到 Delphi 中的每个虚拟方法调用中的东西,在幕后添加 checkPermission 调用(在我看来)都是邪恶的。这会很慢,而且比手工写这样的支票更糟糕。
然而,用于 Mock delphi 类的相同技术将来也许可以用于创建一些自动安全包装对象。
我猜测,如果所讨论的 Java 库使用了方面(本质上是通过代码挂钩等技术实现的“注入”),那么它就不需要到处调用“CheckAllowed”。如果您不介意将所有方法调用更改为实现接口,然后提供执行方法调用的包装器,并在其周围使用某种自动生成的模拟安全包装器,则可以避免调用 CheckAllowed。
所以一个谨慎的“不”,带有“未来可能的有限框架”条款。
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
是的,有一个 Delphi 访问控制库 (lkacl) (OpenSource),JCL (OpenSource),它提供了相当全面的安全性功能,最后,如果您的要求真的很高最流行的商业解决方案是TMS 安全系统。
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.