yii2 と rbac のバックエンドのセットアップに関する以前の詳細なチュートリアルで、ルール テーブルが何をするのか疑問に思ったことがあるかどうかはわかりません。 、そしてなぜそれが全体で使用されるのか、プロセス中にこのテーブルには触れませんでしたか?
信じてください。Baidu や Google を試してみて、最終的には竹かごから水を汲み出そうとするだけです。この部分で説明する内容はほとんどありません。
一般的な権限システムについては、ルールがなくても、以前に作成した rbac で十分であることが多いと思います。
この謎のルールがどうなっているのか、公式サイトの例を使って具体的な操作チュートリアルをしていきます!
需要に応じて:
記事システムには管理者と一般ユーザーがおり、管理者は記事に対するあらゆる操作を行うことができますが、作成した記事を変更できるのは一般ユーザーのみであることに注意してください。記事の変更が許可されていないという意味でも、すべての記事を変更することが許可されているという意味でもありません。
yii2 rbac ルールの実装方法を見てください。焦点は、このルールの使用方法を全員に教えることと、多くの人々の心の問題を解決することです。
ルールを追加する前に、yiirbacRule クラスの実行メソッドを実装する必要があります。
リーリーその後、バックグラウンド ルール リスト (/admin/rule/index) に移動してルールを追加できます。具体的な追加方法については、以下のスクリーンショットを参照してください
上記の手順でクラス名の追加に失敗する人が多いことに注意してください。ArticleRule ファイルが配置されている場所に名前空間を追加することを忘れないでください。
3 番目のステップを見てみましょう。これも間違いを犯しやすい場所です。このチュートリアルに注目してください。この先には大きなエネルギーが待っています。
アクセス権限リスト (/admin/permission/index) に新しい権限を追加しました。この権限は記事を変更するためのものであり、ユーザーのロールに割り当てられます。
ここで重大な警告があることに注意してください。ここで新しく追加された権限によって制御されるルート、つまり記事の更新操作 (/article/update) は現在のユーザーに 1 回だけ割り当てられる可能性があります。ロールまたはユーザーに繰り返し割り当てられているルールは無効であり、失敗の理由は上書きです。この時点で、記事の更新ページ (/article/update/1) を再度更新すると、明らかに 403 アクセス禁止プロンプトが直接表示されます。これは、追加したルールが有効になったことを意味します。現時点で反映されない場合は、上記2点を確認してみてください!
次に、ArticleRule::execute メソッドにビジネス ロジックを実装します。以下を参照してください。
リーリー
最後のステップは、実装したルール認証が機能したかどうかを確認することです。参考のため、テスト手順は次のとおりです:
[現在、ほとんどの国内ウェブサイトが非常に頻繁に記事を収集しており、原文の出典を示していないものさえあることを考慮すると、原作者は読者が問題を防ぐために原文を確認し、誤解を招くことを避けるためにすべての記事を更新しないことを望んでいます! ]
元のテキストを表示