でグループを表すためにロール システムを使用することに限定されるわけではありませんZend_Acl
。
例えば:
あるアプリケーションでは、ベース ユーザー オブジェクトを実装Zend_Acl_Role_Interface
しています。この場合は、ユーザー固有の文字列を返します。user-1
簡単にするために、数字部分がユーザーの一意の ID である のようなものとしましょう。
ユーザー オブジェクトが初期化されると、それ自体が ACL に追加され、ユーザー固有のロールがより一般的なロール (グループに似ています) から継承されます。
if(!$acl->hasRole($this)) {
$acl->addRole($this, $this->role); // Let's say role == 'member' here
}
これにより、親ロール (またはロール) の一般的なルールを設定できます。配列を 2 番目の引数として addRole に渡して、複数の親を持つことができます。また、ロールにはツリーのずっと上に系統があるので、親この場合の役割は、親の役割自体を持つこともできます)。
したがって、ここで柔軟性を説明するために、この基本的な ACL の設定を想定してみましょう (これはすべて理論的なものであり、この回答の目的だけのために書いています)。
$acl->addRole('guest');
$acl->addRole('member', 'guest');
$acl->allow('guest', 'comments', 'read');
$acl->allow('member', 'comments', 'write');
$user = $My_User_Model->find(1);
$acl->allow($user, 'comments', 'moderate');
$acl->isAllowed($user, 'comments', 'read'); // true
$acl->isAllowed($user, 'comments', 'write'); // true
$acl->isAllowed($user, 'comments', 'moderate'); // true
$acl->isAllowed('member', 'comments', 'moderate'); // false
等々...
Zend Framework コンポーネントの優れた点は、それらを 1 つの特定の方法で使用することにまったく制限されないことです。はい、これは困難な場合もあり、多くの場合、最初の計画と実装にもう少し時間を費やす必要がありますが、長期的には素晴らしいことです。
また、個人的には、ACL 特権をコントローラー/アクション構造に直接マッピングすることは好きではありません。しかし、それはまったく別の会話です。