[Yii][RBAC]YiiにおけるRBAC完全ガイドの適用
準備を始める
Yiiは強力な設備メカニズムと多くの既存のクラスライブラリを供給している.YiiでRBACを適用するのは簡単で、RBACコードを書く必要は全くありません.だから準備は、エディタを開けて、私と一緒に来ることです.
パラメータの設定、ツリー・データベースの構築
デバイス配列で、次の内容を追加します.
では、この3つのデータテーブルはどのように木を建てますか?簡単ですframework/web/auth/schemaを見に行きます.sql.カスタマイズしたテーブル名に対応することを重視します.例えばSQLファイルのAuthItemをpreに変更しますauth_item.その後、このSQLファイルの文をデータベースで実行します.
概念をわきまえる
残りのコードは?もうないと言ったよ.RBACシステムはこのように構築された.しかし、それを応用するためには、その運行メカニズムを理解する必要があります.私はできるだけ煩わしいことを言います......(公式のRBACドキュメントはここにありますが、私は4-5回見てからよく聞きました.)
3つの概念
ライセンスプロジェクトはoperations(ステップ)、tasks(タスク)、roles(ロール)に分けられることを理解する必要があります.
1人のユーザーは1つ以上の役割を持っています.例えば、銀行総裁、銀行員、顧客の3つの役割があります.次のように仮定します.
*張総裁の役割:銀行総裁、銀行員、顧客(人自身が貯金できますか).
*王さんには銀行員、お客様という役があります.
*李さんは役があります:お客様.
では、応答して、お客様ができる仕事さえすれば、李さんはできます.王さんと張総裁もできます.銀行員ができる仕事は、王さんも張総裁もできるので、李さんはできません.
例えば、「顧客」が貯金できるなら、「顧客」の役割を持つ張総裁、王人員、李さんは貯金できる.「銀行員」は顧客の取引記録を印刷することができて、それでは「銀行員」の役の張総裁と王員があってもいいですが、李さんはできません.「銀行員」の役のある人を探して具体的な取引記録を印刷しなければなりません.「銀行総裁」が銀行の金庫に入ってお金を引き出すことができるのは、張総裁だけができる.それは「銀行総裁」の役割があるからだ.
これがロールベースの認証体系であり,RBACと略称する.
ロールの継続
役割は持続可能です.たとえば、次のように規定されています.
*「銀行頭取」はすべて「銀行員」です.つまり、銀行員ができる仕事なら、銀行頭取ができるということです.
*すべての「銀行員」は顧客であり、同様に、顧客ができる仕事は銀行員でもできる.
では、キャラクター関係は次のようになります.
*張総裁の役割:銀行総裁.
*王さんには役があります.銀行の人です.
*李さんは役があります:お客様.
これはもっと簡単で、これが役の持続です.
タスクの継続
一つのタスク(task)は別のタスクを含むことができます.例えば、「銀行に入る」などです.
私たちは「顧客」という役に「銀行に入る」権限を設定します.つまり、「顧客」は「銀行に入る」という任務を果たすことができる.次に、「カウンターに入る」ことが銀行に入る親の権限であると仮定します.つまり、「カウンターに入る」には「銀行に入る」が含まれています.「カウンターに入る」ことができる人なら誰でも「銀行に入る」ことができます.私たちは「カウンターに入る」という任務権限を「銀行員」に与えた.
では、役から言えば、王人員は銀行に入ることができます.王人員の役は「銀行員」であり、「銀行員」には「顧客」の役が含まれているからです.では、「顧客」が行える「タスク」は「銀行員」にとっても可能です.「顧客」は「銀行に入る」ことができ、王員も「銀行に入る」ことができる.これはキャラクターの持続がもたらしたものです.
趙さんの指導があると仮定して、上司の指導で、カウンターに入って観察することができます.では、私たちの任務関係は次のとおりです.
*趙さんの指導には任務があります.カウンターに入ります.
では、趙指導は「銀行に入る」ことができる.「銀行に入る」ことは「カウンターに入る」ことに含まれる任務だからだ.「カウンターに入る」ことができる人なら誰でも「銀行に入る」ことができます.これが任務の継続である.
歩行について
歩行は区分できない一級である.つまり.1つの足取りには他の足取りを含めることはできません.「銀行の倉庫からお金を引き出す」という足取りがあるとします.私たちはこの足取りを「カウンターに入る」ことを含んでいます.では、「銀行倉庫からお金を引き出す」という役割を果たせば、「カウンターに入る」という任務を果たすことができます.
三者関係
*1つのロールには、他の1つまたは複数のロールを含めることができます.
*1つのロールには、他の1つまたは複数のタスクを含めることができます.
*1つのキャラクターには、他の1つまたは複数のステップを含めることができます.
*
*1つのタスクには、他の1つまたは複数のタスクを含めることができます.
*1つのタスクには、別のステップを1つまたは複数含めることができます.
*
*1つのステップは、キャラクターまたはタスクにのみ含まれます.ステップは、他のステップも含められず、再分割されません.
これにより、権限管理システムが形成されます.「任務」と「足取り」については、文字通りの意味を考える必要はありません.この2つが2つの権限を形成している.
権限を与える
我々はRBAC権限管理を構築し,権限に対するWEB管理を行う必要がある.これらはあなた自身がコードを書く必要があります.
種類に合わない項目に従って以下の方法の必然的な意味で項目を授権する.
* CAuthManager::createRole
* CAuthManager::createTask
* CAuthManager::createOperation
ライセンス・プロジェクトを1つ所有すると、次の方法を呼び出して、ライセンス・プロジェクト関係を構築できます.
* CAuthManager::addItemChild
* CAuthManager::removeItemChild
* CAuthItem::addChild
* CAuthItem::removeChild
最後に、ロール・アイテムを各ユーザーに割り当てるには、次の方法を呼び出します.
* CAuthManager::assign
* CAuthManager::revoke
次に、供給されたAPIを使用してライセンスレベルをツリー化する例を示します.
￥auth=Yii::app()->authManager;
￥auth->createOperation(""createPost"",""create a post"");
￥auth->createOperation(""readPost"",""read a post"");
￥auth->createOperation(""Post"",""a post"");
￥auth->createOperation(""Post"",""a post"");
￥bizRule=""return Yii::app()->user->id==￥params["post"]->authID;"";
￥task=￥auth->createTask(""OwnPost"",""a post by author himself"",￥bizRule);
￥task->addChild(""Post"");
￥role=￥auth->createRole(""reader"");
￥role->addChild(""readPost"");
￥role=￥auth->createRole(""author"");
￥role->addChild(""reader"");
￥role->addChild(""createPost"");
￥role->addChild(""OwnPost"");
￥role=￥auth->createRole(""editor"");
￥role->addChild(""reader"");
￥role->addChild(""Post"");
￥role=￥auth->createRole(""admin"");
￥role->addChild(""editor"");
￥role->addChild(""author"");
￥role->addChild(""Post"");
￥auth->assign(""reader"",""readerA"");
￥auth->assign(""author"",""authorB"");
￥auth->assign(""editor"",""editorC"");
￥auth->assign(""admin"",""adminD"");
つまり、あなたは自分で管理インタフェースを書いて、あなたの役、任務、足取りをリストして、それからこのインタフェースで管理することができます.例えば、成長、削除、承認などです.
権限の検索
管理インタフェースで権限を付与したと仮定すると、法度で権限検索を行うことができます.
上のコードでは、ユーザーが「createPost」を実行できるかどうかを確認します.このcreatePostはタスクであり、ステップである可能性があります.
その他
多くのYii権限体系RBACが使いにくいと言っている人には、実際にはドキュメントが読めません.私の体験を総合すると、YiiフレームのRBACは私が使ったフレームの中で一番使いやすいと感じました.そして自分でコードを書く必要があります.
YiiのRBACには「営業規則」「デフォルトキャラクター」など、倍以上の使い方があります.公式文書を参考にすることができます.
私は、プロジェクトチームの人がRBACを真似したり、理解したりしないか、YiiのRBACを使わないことを知っています.大丈夫です.私のコメントボックスで質問してもいいです.
happy Yii !
Yiiは強力な設備メカニズムと多くの既存のクラスライブラリを供給している.YiiでRBACを適用するのは簡単で、RBACコードを書く必要は全くありません.だから準備は、エディタを開けて、私と一緒に来ることです.
パラメータの設定、ツリー・データベースの構築
デバイス配列で、次の内容を追加します.
‘components‘ => array（
//……
‘authManager‘=>array（
‘class‘=>‘CDbAuthManager‘，//
‘defaultRoles‘=>array（‘guest‘），//
‘itemTable‘ => ‘pre_auth_item‘，//
‘itemChildTable‘ => ‘pre_auth_item_child‘，//
‘assignmentTable‘ => ‘pre_auth_assignment‘，//
），
//…… では、この3つのデータテーブルはどのように木を建てますか?簡単ですframework/web/auth/schemaを見に行きます.sql.カスタマイズしたテーブル名に対応することを重視します.例えばSQLファイルのAuthItemをpreに変更しますauth_item.その後、このSQLファイルの文をデータベースで実行します.
概念をわきまえる
残りのコードは?もうないと言ったよ.RBACシステムはこのように構築された.しかし、それを応用するためには、その運行メカニズムを理解する必要があります.私はできるだけ煩わしいことを言います......(公式のRBACドキュメントはここにありますが、私は4-5回見てからよく聞きました.)
3つの概念
ライセンスプロジェクトはoperations(ステップ)、tasks(タスク)、roles(ロール)に分けられることを理解する必要があります.
1人のユーザーは1つ以上の役割を持っています.例えば、銀行総裁、銀行員、顧客の3つの役割があります.次のように仮定します.
*張総裁の役割:銀行総裁、銀行員、顧客(人自身が貯金できますか).
*王さんには銀行員、お客様という役があります.
*李さんは役があります:お客様.
では、応答して、お客様ができる仕事さえすれば、李さんはできます.王さんと張総裁もできます.銀行員ができる仕事は、王さんも張総裁もできるので、李さんはできません.
例えば、「顧客」が貯金できるなら、「顧客」の役割を持つ張総裁、王人員、李さんは貯金できる.「銀行員」は顧客の取引記録を印刷することができて、それでは「銀行員」の役の張総裁と王員があってもいいですが、李さんはできません.「銀行員」の役のある人を探して具体的な取引記録を印刷しなければなりません.「銀行総裁」が銀行の金庫に入ってお金を引き出すことができるのは、張総裁だけができる.それは「銀行総裁」の役割があるからだ.
これがロールベースの認証体系であり,RBACと略称する.
ロールの継続
役割は持続可能です.たとえば、次のように規定されています.
*「銀行頭取」はすべて「銀行員」です.つまり、銀行員ができる仕事なら、銀行頭取ができるということです.
*すべての「銀行員」は顧客であり、同様に、顧客ができる仕事は銀行員でもできる.
では、キャラクター関係は次のようになります.
*張総裁の役割:銀行総裁.
*王さんには役があります.銀行の人です.
*李さんは役があります:お客様.
これはもっと簡単で、これが役の持続です.
タスクの継続
一つのタスク(task)は別のタスクを含むことができます.例えば、「銀行に入る」などです.
私たちは「顧客」という役に「銀行に入る」権限を設定します.つまり、「顧客」は「銀行に入る」という任務を果たすことができる.次に、「カウンターに入る」ことが銀行に入る親の権限であると仮定します.つまり、「カウンターに入る」には「銀行に入る」が含まれています.「カウンターに入る」ことができる人なら誰でも「銀行に入る」ことができます.私たちは「カウンターに入る」という任務権限を「銀行員」に与えた.
では、役から言えば、王人員は銀行に入ることができます.王人員の役は「銀行員」であり、「銀行員」には「顧客」の役が含まれているからです.では、「顧客」が行える「タスク」は「銀行員」にとっても可能です.「顧客」は「銀行に入る」ことができ、王員も「銀行に入る」ことができる.これはキャラクターの持続がもたらしたものです.
趙さんの指導があると仮定して、上司の指導で、カウンターに入って観察することができます.では、私たちの任務関係は次のとおりです.
*趙さんの指導には任務があります.カウンターに入ります.
では、趙指導は「銀行に入る」ことができる.「銀行に入る」ことは「カウンターに入る」ことに含まれる任務だからだ.「カウンターに入る」ことができる人なら誰でも「銀行に入る」ことができます.これが任務の継続である.
歩行について
歩行は区分できない一級である.つまり.1つの足取りには他の足取りを含めることはできません.「銀行の倉庫からお金を引き出す」という足取りがあるとします.私たちはこの足取りを「カウンターに入る」ことを含んでいます.では、「銀行倉庫からお金を引き出す」という役割を果たせば、「カウンターに入る」という任務を果たすことができます.
三者関係
*1つのロールには、他の1つまたは複数のロールを含めることができます.
*1つのロールには、他の1つまたは複数のタスクを含めることができます.
*1つのキャラクターには、他の1つまたは複数のステップを含めることができます.
*
*1つのタスクには、他の1つまたは複数のタスクを含めることができます.
*1つのタスクには、別のステップを1つまたは複数含めることができます.
*
*1つのステップは、キャラクターまたはタスクにのみ含まれます.ステップは、他のステップも含められず、再分割されません.
これにより、権限管理システムが形成されます.「任務」と「足取り」については、文字通りの意味を考える必要はありません.この2つが2つの権限を形成している.
権限を与える
我々はRBAC権限管理を構築し,権限に対するWEB管理を行う必要がある.これらはあなた自身がコードを書く必要があります.
種類に合わない項目に従って以下の方法の必然的な意味で項目を授権する.
* CAuthManager::createRole
* CAuthManager::createTask
* CAuthManager::createOperation
ライセンス・プロジェクトを1つ所有すると、次の方法を呼び出して、ライセンス・プロジェクト関係を構築できます.
* CAuthManager::addItemChild
* CAuthManager::removeItemChild
* CAuthItem::addChild
* CAuthItem::removeChild
最後に、ロール・アイテムを各ユーザーに割り当てるには、次の方法を呼び出します.
* CAuthManager::assign
* CAuthManager::revoke
次に、供給されたAPIを使用してライセンスレベルをツリー化する例を示します.
￥auth=Yii::app()->authManager;
￥auth->createOperation(""createPost"",""create a post"");
￥auth->createOperation(""readPost"",""read a post"");
￥auth->createOperation(""Post"",""a post"");
￥auth->createOperation(""Post"",""a post"");
￥bizRule=""return Yii::app()->user->id==￥params["post"]->authID;"";
￥task=￥auth->createTask(""OwnPost"",""a post by author himself"",￥bizRule);
￥task->addChild(""Post"");
￥role=￥auth->createRole(""reader"");
￥role->addChild(""readPost"");
￥role=￥auth->createRole(""author"");
￥role->addChild(""reader"");
￥role->addChild(""createPost"");
￥role->addChild(""OwnPost"");
￥role=￥auth->createRole(""editor"");
￥role->addChild(""reader"");
￥role->addChild(""Post"");
￥role=￥auth->createRole(""admin"");
￥role->addChild(""editor"");
￥role->addChild(""author"");
￥role->addChild(""Post"");
￥auth->assign(""reader"",""readerA"");
￥auth->assign(""author"",""authorB"");
￥auth->assign(""editor"",""editorC"");
￥auth->assign(""admin"",""adminD"");
つまり、あなたは自分で管理インタフェースを書いて、あなたの役、任務、足取りをリストして、それからこのインタフェースで管理することができます.例えば、成長、削除、承認などです.
権限の検索
管理インタフェースで権限を付与したと仮定すると、法度で権限検索を行うことができます.
if（ Yii::app（）->user->checkAccess（""createPost""） ）
{
//
} else {
//
} 上のコードでは、ユーザーが「createPost」を実行できるかどうかを確認します.このcreatePostはタスクであり、ステップである可能性があります.
その他
多くのYii権限体系RBACが使いにくいと言っている人には、実際にはドキュメントが読めません.私の体験を総合すると、YiiフレームのRBACは私が使ったフレームの中で一番使いやすいと感じました.そして自分でコードを書く必要があります.
YiiのRBACには「営業規則」「デフォルトキャラクター」など、倍以上の使い方があります.公式文書を参考にすることができます.
私は、プロジェクトチームの人がRBACを真似したり、理解したりしないか、YiiのRBACを使わないことを知っています.大丈夫です.私のコメントボックスで質問してもいいです.
happy Yii !