権限管理

機能

@nocobase/app-plugin-authorization は、権限セット、ページと設定へのアクセス、業務操作、データベースのフィールド、レコード、リレーションのポリシーを提供します。

リソースと管理画面はアプリが宣言し、認可の判定とデータのポリシーはプラグインが提供します。

アクセスを設定する

リソースと操作は宣言する必要があります。テーブルがあるだけでは、そのコレクションは権限のモデルに登録されません。

設定された root の権限セットは unrestricted で、通常の業務のロールとは分けておくべきです。現在のアカウントの作成では Member を明示的に割り当てます。サインインしたすべてのユーザーに、暗黙で避けられない権限として付くわけではありません。

シナリオと例

例：注文の閲覧と編集

1. フィールドとレコードの選択を含め、閲覧と編集の機能を宣言します。
2. サポートの担当者に閲覧のアクセスを、担当するユーザーに必要な編集のアクセスを付与します。
3. ナビゲーションとボタンにはルートの authz と useCan を使い、API でも操作を改めて確認します。
4. authz.database.policyFor(...) や authorizeRepository(...) などの公開のメソッドで、レコードとフィールドのポリシーを適用します。
5. 異なるロールで、一覧、詳細、リレーション、API の直接の呼び出しを検証します。

操作のチェックのあとに制限のない照会を行うと、レコードとフィールドの制限が失われます。ナビゲーションを隠すことは、サーバーの認可ではありません。

開発用のプロンプト（アプリのディレクトリで作業するコーディングエージェント向け）：

Authorization を使って、注文の閲覧と編集のアクセスを追加してください。ページと業務操作を
宣言し、既存のロールを再利用し、root や unrestricted の付与は追加しないでください。
画面の操作を制御し、サーバー側で操作、レコード、フィールドのポリシーを強制してください。
閲覧専用、編集、拒否されるユーザーとして、一覧、詳細、リレーション、API の直接の呼び出しを
テストしてください。

完了の条件閲覧専用のユーザーが許可された注文を読めるが編集できないこと。ほかのレコードと制限されたフィールドにはアクセスできないままであること。

主な仕組みと実装

以下は、この例での組み込みの領域と、想定される画面の変化です。開発作業を記述したもので、実際のファイル構成はアプリに合わせてください。

組み込みと入口

Client と Server のプラグインは Authentication のあとに登録し、マイグレーションとシードを適用します。設定は server/config/authorization.ts で組み立て、信頼できるサーバーの組み込みには /server から authorizationToken を解決します。

プラグインは、/api/authorization、AuthorizationClient、useCan などのフックを公開します。権限管理のページはアプリが作り、付与できる業務の機能を宣言します。

レコードアクセスの拡張

• 既定のデータアクセス は、すでに付与された操作に共通のレコードの基準を追加します。
• 共有ルール は、指定した主体に選んだレコードを追加します。
• 制限ルール は、それらの主体が引き続きアクセスできるレコードを絞り込みます。

どれも操作の権限は付与しません。管理画面でのまとめ方も、認可には影響しません。インストールについては プラグインを管理する を参照してください。

AI 開発の制約と検証

プラグイン固有の開発の制約

• 付与する前に機能を宣言してください。権限のモデルの外にあるデータベースの照会は、それらの付与では保護されません。
• 真偽値の can の結果のあとに制限のない照会を行うだけでなく、ページ、操作、フィールド、レコード、リレーションを確認してください。
• 通常のロールと API の直接のリクエストを使ってください。ロールのシードを変更するときは、既存のアクセスが意図せず広がっていないかを確認してください。

これらはあなたの組み込みの検収の要件であり、実機での検証が完了したことを示すものではありません。実際の変更、実行したチェック、未検証の項目をエージェントに報告させてください。プロジェクトのガイダンス、スキル、共通のチェックについては アプリの開発を続ける と テスト を参照してください。

出典：公開のプラグインの入口と実装。