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