0

私は PhaseListener を使用しています。私の認証情報は RESTORE_VIEW から INVOKE_APPLICATION と RENDER_RESPONSE まで直接利用できることがわかります。これはすべて理にかなっています。これらの資格情報の検証に関しては、どのようなベスト プラクティスがあるのだろうか。

RESTORE_VIEW で検証できると考えています。UPDATE_MODEL がセキュリティ上のリスクになる可能性があるため、UPDATE_MODEL まで待ちたくないと確信しています。フェーズを APPLY_REQUEST と PROCESS_VALIDATIONS で実行する必要があるかどうかは、もう少し不確かですが...

何か案は？

4

2 に答える 2

4

実際には、RESTORE_VIEWフェーズは、JSF リソースへのアクセス制御を適用する理想的な場所です。これは、ページのリクエスト ライフサイクルの最初のフェーズです。承認されていない場合、リクエストをそれ以上進行させる理由はありません。

アクセス制御などの基本的なサービスのフェーズとフェーズリスナーについて大騒ぎするべきではないという事実は別として、(この回答の時点で) aPhaseListenerが注入ターゲットではないという事実に遭遇する可能性があります。 . これが意味することは@EJB、@Injectと@ManagedPropertyはフェーズリスナーでは機能しないということです。あなたがそれをしない限り@ManagedBean。これは、認証チェックを実行するために必要なサービスがフェーズリスナーで利用できないことを意味します。JSF2.2 は、コンテキスト内のすべてのものをインジェクション ターゲットにすることを約束していますが、

私は「ベスト プラクティス」の権威ではありませんが、ベスト プラクティスの私の考えは、問題を解決するためのクリーンで保守可能で再利用可能なアプローチです。IMO、ページへのアクセス制御のクリーンで低侵襲の 2 つの方法は次のとおりです。

  1. Servlet Filter : これは、テスト済みの真の Web リソース アクセス制御方法であり、JSF に依存しません。フェーズなど、ほとんどすべての J2EE について心配する必要はありません。 これは、JSF リソースを保護するサーブレット フィルターの非常にわかりやすい例です。

  2. JSF ページ レベル認証: JSFpreRenderViewイベントを使用して、JSF ページへのアクセスを検証できます。これは本質的にRESTORE_VIEWフェーズ中に開始され、その使用に関してここにたくさんのリソースがあります。

于 2013-06-11T04:28:24.883 に答える