使用Apache Shiro并保留Java EE的本地 API 用于安全性和会话管理有什么优势?
我发现所有安全角色和会话都可以在 Apache Shiro 中完成,但同样的事情也可以使用 Java EE 安全性来完成,而无需任何外部依赖 jar。
所以建议我一些去 Apache Shiro 的利弊。
使用Apache Shiro并保留Java EE的本地 API 用于安全性和会话管理有什么优势?
我发现所有安全角色和会话都可以在 Apache Shiro 中完成,但同样的事情也可以使用 Java EE 安全性来完成,而无需任何外部依赖 jar。
所以建议我一些去 Apache Shiro 的利弊。
我当然是有偏见的(我是 Apache Shiro 项目的提交者),所以请随心所欲,但这是我的意见:
Java EE Security 不支持开箱即用的独立于容器的会话集群选项(Shiro 支持)。
Shiro 从一开始就被设计为在 POJO/依赖注入环境中工作。它使用接口驱动设计,并提供比传统 Java EE 安全环境更多的自定义钩子(例如,您如何显示当前有多少用户使用 Java EE 安全登录到您的站点?Shiro 可以帮助您显示这一点)。
Shiro 在任何应用程序环境中都是完全可移植的。如果您使用 Java EE 供应商特定的安全定制,那么这些定制将不可移植(例如,这个StackOverflow 问题表明切换到 JBoss 可能会解决用户的安全问题 - IMO 的一个令人不安的答案)。
与特定于服务器的定制一样,许多 Java EE 安全教程、文章和博客文章向您展示了基于用户界面的配置,这些配置以不同的方式跨平台解决问题,并且如果您切换到重新学习可能会令人沮丧。此外,Java EE 配置通常需要 XML。我更喜欢可以在任何地方使用的单一的、非冗长的文本配置格式(shiro.ini 很好,但人们也可以使用 groovy、yaml 等配置 shiro)。
Shiro 旨在在任何应用程序环境中工作。Java EE 安全性设计得很好 - 仅适用于 Java EE。至少当您学习 Shiro 时,您可以在任何基于 JVM 的应用程序(Spring、Guice、Java EE、命令行等)中利用这些知识,而不仅仅是 Java EE 应用程序。
!
莱斯