15.6.2. コンポーネントをセキュアにする
最も簡単な形式の承認、コンポーネントのセキュリティから見ていくことにします。
@Restrict アノテーションから始めましょう。
注記
@Restrict アノテーションはセキュリティコンポーネントに対してパワフルで柔軟なメソッドですが、EL 式に対応できません。 したがって、 コンパイル時の安全性のためタイプセーフと同等の方法を使用することをお勧めします (本章後半に記載)。
15.6.2.1. @Restrict アノテーション リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
@Restrict アノテーションにより Seam のコンポーネントはクラスあるいはメソッドいずれかのレベルでの安全化を図ることができます。 メソッドとその宣言クラスの両方に @Restrict アノテーションを付与すると、 メソッドの制限が優先されるためクラスの制限は適用されません。 メソッド呼び出しがセキュリティチェックに失敗した場合には、 Identity.checkRestriction() のコントラクトに応じて例外が送出されます (Inline Restriction については本項の後半を参照)。 コンポーネントクラス自体での @Restrict は、 そのメソッドそれぞれに @Restrict を追加したのと同じことになります。
空の
@Restrict は component:methodName のパーミッションチェックを暗示します。 次のコンポーネントメソッドの例を見てみましょう。
この例では
account:delete は、delete() メソッドを呼び出すために必要な暗黙権限です。これは @Restrict("#{s:hasPermission('account','delete')}") と記述するのと同等です。 別の例についても見てみます。
ここでは、 コンポーネントクラス自体に
@Restrict アノテーションが付与されています。 つまり @Restrict アノテーションを上書きしないメソッドはすべて暗黙のパーミッションチェックが必要になります。 この例の場合、 insert() メソッドには account:insert のパーミッションが必要となり、 delete() メソッドにはユーザーが admin ロールのメンバーであることが必要となります。
先に進む前に、 上の例で見た
#{s:hasRole()} 式について見てみましょう。 s:hasRole も s:hasPermission も EL 式であり、 Identity クラスの同様の名前のメソッドに委任します。 こうした関数は EL 式内でセキュリティ API 全体に渡り使用することができます。
EL 式とすることで、
@Restrict アノテーションの値は Seam コンテキスト中のいずれのオブジェクトでも参照することができるようになります。 特定のオブジェクトのインスタンスのパーミッションをチェックする場合に非常に有効な方法です。 下の例を見てみましょう。
この例では、
hasPermission() 関数呼び出しは selectedAccout を参照しています。 この変数の値は Seam コンテキスト中で検索され、 Identity 内の hasPermission() メソッドに渡されます。 これにより特定の Account オブジェクトの変更に要されるパーミッションをユーザーが持っているかどうかを判断します。