Spring @Transactional v Spring Security @Secured 行为不一致

发布于 2024-12-20 06:16:44 字数 520 浏览 7 评论 0 原文

Spring 文档建议将 @Transactional 注释放在具体的类/方法上,而不是接口上。其原因已在 Stack Overflow 上多次介绍,例如:

我应该在哪里放置 @Transactional 注解:在接口定义处还是在实现类处?

Spring Security @Secured 行为不同;大多数文档显示将注释放在界面上。事实上,无论您注释接口还是具体类,也无论您使用 JDK 还是 CGLib 代理,它似乎都有效。

这似乎是一个更好的解决方案。那么为什么会出现不一致呢?上述问题的一个答案表明会对性能产生影响……但性能对于安全来说肯定同样重要吗?!

@Secured 解决方案如何处理钻石继承问题(类实现 2 个接口,两者都具有不同的 @Secured 相同方法)?

Spring documentation advises putting the @Transactional annotation on the concrete class/method rather than the interface. The reason for this has been covered on Stack Overflow many times, eg:

Where should I put @Transactional annotation: at an interface definition or at an implementing class?

Spring Security @Secured behaviour differs; most documentation shows placing the annotation on the interface. In fact it seems to work whether you annotate the interface or the concrete class and regardless of whether you use JDK or CGLib proxies.

This seems a superior solution. So why the inconsistency? One answer to the above question suggests a performance impact... but surely performance is just as important to security?!

And how does the @Secured solution deal with the diamond inheritance problem (class implements 2 interfaces both have @Secured same method differently)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟若柳尘 2024-12-27 06:16:44

当同时使用 JDK 代理和 CGLib 时,您最终会得到 事务拦截器 href="http://static.springsource.org/spring/docs/current/javadoc-api/org/springframework/transaction/annotation/Transactional.html" rel="nofollow">@Transactional 和 MethodSecurityInterceptor 用于 @Secured

但这两个 MethodInterceptor 使用不同的机制来查找给定 < 上的注释a href="http://aopalliance.sourceforge.net/doc/org/aopalliance/intercept/MethodInvocau.html" rel="nofollow">方法调用。

@Secured 注释可通过 SecuredAnnotationSecurityMetadataSource 使用 AnnotationUtils.findAnnotation(Method method, ClassannotationType) 方法,而 @Transactional 是由 AnnotationTransactionAttributeSource 发现在 SpringTransactionAnnotationParser

看起来 AnnotationUtils 具有更先进的机制来查找注释、搜索接口和声明类层次结构的方法。

您可以创建自己的 TransactionAnnotationParser< /a> 使用 AnnotationUtils,这应该启用与 @Transactional 相同的功能。

AnnotationUtils 返回第一个找到的注释,这就是钻石继承的处理方式。

When using both JDK proxies and CGLib You end up with TransactionInterceptor for @Transactional and MethodSecurityInterceptor for @Secured.

But those two MethodInterceptors use diffrent mechanisms to find annotation on given MethodInvocation.

@Secured annotation is found by SecuredAnnotationSecurityMetadataSource using AnnotationUtils.findAnnotation(Method method, Class<A> annotationType) method, while @Transactional is discovered by AnnotationTransactionAttributeSource with help of SpringTransactionAnnotationParser.

It looks like AnnotationUtils have much more advanced mechanisms of finding annotations, seraching both the interfaces and the method declaring class hierarchy.

You could create Your own TransactionAnnotationParser that uses AnnotationUtils and this should enable same functioanlity to @Transactional.

AnnotationUtils returns the first found annotation, so that's how diamond inheritance is dealt with.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文