私は GlassFish 3.1 を使用しており、コンテナー認証を使用したいと考えていました。web.xml にセキュリティ制約を書き始めたとき、URL パターンには柔軟性がほとんどないと感じました。サーブレット仕様 3.0 の 12.2 章では、サーブレット マッピングの有効な URL パターンについて説明しています。
- リスト項目
- /some/* パス マッピング用
- *拡張子マッピングの拡張子
- 正確なマッピング
- デフォルトおよびコンテキスト ルート ケース
12.1 はマッチング アルゴリズムを説明し、ポイント 2 で次のように述べています。これは、パス セパレータとして「/」文字を使用して、一度に 1 ディレクトリずつパス ツリーをステップ ダウンすることによって行われます。最長一致によって、選択されるサーブレットが決まります。
セキュリティ制約については 13 章で説明されており、13.8.3 からは url-patterns とマッチング アルゴリズムはサーブレットのものと同じようです。
次のように編成された JSF ページを持つレガシー アプリケーションがあるとします。エンティティ クラスごとに、4 つの JSF ファイル (リスト、編集、作成、表示) を含むエンティティ名を持つディレクトリがあります。ページを編集および作成するためのアクセスを保護したい場合はどうすればよいでしょうか? URLパターンで「完全一致」のみを使用できるように思われるため、保護したいページごとに制約を記述する必要があり、非常に長くて面倒で、エラーが発生しやすいアクティビティです。さらに、ディレクトリ全体をパス マッピング ルール ( /customers/*など) で保護すると、そのディレクトリ内の特定のページの制約を緩和する方法がわかりません (たとえば、ページへのアクセスを解放したい場合)リスト」は保護されたディレクトリ内にあります)。
Glassfish 3.1 での実験中に、この奇妙な動作に気付きました。パス マッピングは、コンテキスト ルートからの絶対パスである場合にのみうまく機能するため、jsf のデフォルト設定を使用すると、' /faces ' で開始する必要があります。/顧客/と書くと/faces/customers/の代わりに、セキュリティ制約は評価されません。私によると、これは 12.1 で述べられていること (上記で報告) とは対照的です。
セキュリティ制約を定義するために url-pattern を効果的に使用する方法について、誰かが光を当てることができますか? 明らかに、すべての機密性の高い JSF を「/protected」ディレクトリ内に配置できますが、これは、JSF の論理的な順序を破るセキュリティで目標を達成するための非常に侵略的な方法です。
ありがとうフィリッポ