1

私は ICEfaces にはまったく慣れていませんが、JSF/Facelets と Java EE 全般の経験はすでにあります。

現在、outputStyle や outputDeclaration などのいくつかのユーティリティ タグを除いて、ICEface の多くを使用していませんが、これさえあれば本当に便利です。

後でいくつかの AJAX 機能を使用する予定ですが、/block/send-receive-updates を介さずに、通常の JSF POST 要求として送信したい h:forms (または ice:forms) がいくつかあります。その理由は、要求された URI に作用するフィルターを使用したいからです。これは、すべてが /block/send-receive-updates に送信される場合には不可能です。

これを行う方法はありますか？

編集：私がやりたいことを明確にするために：

私たちが開発しているウェブサイトは、一般に公開されているページと、登録されたメンバーのみがアクセスできるページで構成されています。サーブレット標準で定義されている標準の FORM ベースのセキュリティ メカニズムは、制限されたコンテンツにアクセスしたい場合に表示される 1 つのログイン ページしか定義できないため、かなり柔軟性がありません。また、ユーザーがすべてのページに表示される小さなログイン フォームを使用してログインできるようにしたいため、Web コンテナーのように認証と承認を処理するフィルターを開発しました。ユーザーが認証/許可されていない場合は、カスタム ログイン ページにリダイレクトされますが、バッキング Bean からユーザーを認証することもできます。ほぼ透過的に機能させるために、HttpServletRequest をラップして、プリンシパルとユーザーの役割を提供します。

フィルターがカスタム ログイン ページにリダイレクトすると、ユーザーが正常に認証されたときに、現在の要求を保存して後で「再生」します。これを行うには、POST リクエストがログイン ページから送信された場合 (したがって、ユーザーが現在認証/承認されている場合) をフィルターが検出できる必要があります。しかし、すべての POST が /block/send-receive-updates 経由で行われる場合、これは機能しなくなります。

もちろん、ログイン ページを ICEfaces で処理しないようにすることもできますが、これは、ログイン ページで ICEfaces/AJAX を使用できないことを意味します。

4

2 に答える 2

1

これはこれを行う最良の方法ではないかもしれませんが、方法かもしれません。議論のために、ヘッダーに追加のログインフォームが保持されていると仮定します。別のフレームまたはメイン レイアウト ページのいずれかにヘッダーを作成し、JSF ページを iframe に埋め込む場合、これは機能する可能性があります。別のページとしてレンダリングされているため、別の方法で処理できるという考えです。

また、これをより IceFaces らしくするセキュリティを処理する別の方法があるかもしれません。おそらく、フィルターにヒットし、ログインしていないと判断された場合、元の要求 (URL、パラメーターなど) からの情報を保持する Bean (おそらくセッション) を作成し、次のように送信します。ログインページ。ログインページは、セキュリティ機能を追加し、そのセッション Bean 内の情報を使用して、新しいページへのリダイレクトを強制します。FacesContext を使用して HttpContext を取得し、リダイレクトを実行できます。適切なパラメーターを追加するには、おそらくリダイレ​​クトをいじる必要があります。最後に、セッション Bean を削除する必要があります。

最後に、リクエストの状態を保存し、ログインを実行させ、最初に行っていた場所にかなりシームレスにリダイレクトするフレームワーク (Spring WebFlow が思い浮かびます) がいくつかあることを知っています(これは、思い出してください、私は Seam もこれを行うことができると思います. おそらく Orchestra や他のフレームワークも同様です.)

お役に立てれば！

于 2009-02-25T00:59:49.840 に答える