セキュリティとセッション管理のためにJava EEのネイティブ API を使用せずにApache Shiroに移行することには、どのような利点がありますか?
すべてのセキュリティ ロールとセッションは Apache Shiro で実行できることがわかりましたが、外部依存 jar なしで Java EE セキュリティを使用して同じことを実行することもできます。
Apache Shiro に行くことの長所と短所を教えてください。
セキュリティとセッション管理のためにJava EEのネイティブ API を使用せずにApache Shiroに移行することには、どのような利点がありますか?
すべてのセキュリティ ロールとセッションは Apache Shiro で実行できることがわかりましたが、外部依存 jar なしで Java EE セキュリティを使用して同じことを実行することもできます。
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 は便利ですが、shiro を groovy、yaml などで構成することもできます)。
Shiro は、あらゆるアプリケーション環境で動作するように設計されています。Java EE セキュリティは、Java EE 専用に設計されています。少なくとも Shiro を学べば、Java EE アプリだけでなく、JVM ベースのあらゆるアプリケーション (Spring、Guice、Java EE、コマンド ラインなど) でその知識を活用できます。
チッ!
レ