1

web.xml で宣言されたセキュリティ制約があります。

    <security-constraint>
    <web-resource-collection>
        <web-resource-name>LoggedIn</web-resource-name>
        <url-pattern>/screens/*</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

ログイン後、アプリケーションに対して GET リクエストを行うと、期待どおりの動作が得られます。

https://localhost:8443/Patrac/screens/user.xhtml--> アクセスが拒否されます。

ただし、たとえばポストバックを行うと

<rich:menuItem submitMode="ajax" label="User" action="/screens/user"/>

画面を見ることができます。2 回目の同一のポストバックを行うと、アクセス拒否メッセージが表示されます。ポストバックを送信するたびに、結果は画面の表示と 403 の発行を交互に繰り返します。ブラウザーに表示される URL は、次のように交互に変わります。

https://localhost:8443/Patrac/screens/user.xhtml--> アクセス拒否時のブラウザ URL

https://localhost:8443/Patrac/public/403.xhtml--> ユーザー画面表示時のブラウザURL

JSF で表示されるブラウザの URL が現在表示されている画面よりも遅れていることは理解しているので、それは謎ではありません。しかし、同じポストバックが送信されるたびに画面を表示する方法がわかりません。ここでも、GET 要求は常に拒否されます。

編集 ：

post-redirect-get を試してみたところ、予想どおり、奇妙な動作がなくなりました。

<rich:menuItem submitMode="ajax" label="User" action="/screens/user?faces-redirect=true"/>

しかし、私は毎回 PRG を実行したくありません。さらに、PRG はセキュリティの問題を排除しません。

ここで何が欠けていますか？洞察をありがとう！

4

1 に答える 1

1

セキュリティ制約は、転送ではなく要求でチェックされます。これは仕様によるものです。

したがって、PRGパターン、またはより適切には通常のGETリンクが必ず必要です。また、すぐにWebアプリがSEOに対応し、ブックマークしやすくなります。ページ間ナビゲーションにPOSTを使用することは、とにかく悪い設計です。

表示されている「代替動作」は、転送がチェックされていないためですが、同じページでの後続の（ポストバック）リクエストは完全に価値のあるリクエストであるため、チェックされます。

于 2012-07-30T20:15:32.747 に答える