Skip to main content
Base44 は、アプリの構築中にデータ権限を自動的にセットアップします。AI チャットを使用していつでも調整したり、より細かい制御が必要な場合は手動で設定したりできます。権限が正しく設定されていない場合、間違った人々がアプリ内のデータを表示または変更する可能性があります。
誰がアプリを開けるか、サインインが必要かを設定するには、アプリアクセスとロールの管理 を参照してください。

​
AI チャットを使用して権限を設定する

権限を手動で設定する必要はありません。AI チャットにアプリがどう動作すべきかを平易な言葉で伝えると、適切なルールを設定します。これは、最初にアプリを構築するときと、ニーズが変わったときの後のいずれにも機能します。既存のルールを更新する必要がある場合は、最初に承認を求めます。 使用できるプロンプトの例:

​
権限を手動でカスタマイズする

特定のデータテーブルの権限をレビューまたは微調整したい場合は、ダッシュボードのテーブルの Permissions ページから行えます。ページは、現在のルールを示す読み取り専用ビューで開きます。Edit をクリックして変更を加えます。
どのルールを設定すべきか分からない? 必要なものを平易な言葉で AI チャットに説明すると、権限を設定します。手動設定は、より正確な制御が必要なときのためにあります。
データテーブルの権限をカスタマイズするには:
  1. アプリエディタで Dashboard をクリックします。
  2. Data の下で、管理したいテーブルをクリックします。
  3. ページの右上にある Permissions をクリックします。権限の問題がある場合、ボタンに警告アイコンが表示されます。
  4. Edit をクリックして Configure permissions パネルを開きます。
  5. 各ルールがカバーするアクションのボックスをチェックします: Create (レコードを追加)、Read (レコードを表示)、Update (レコードを編集)、Delete (レコードを削除)。
  6. Entity-User Field Comparison のボックスをチェックする場合は、Entity field にこのテーブルから比較するフィールドを入力し、次に User field ドロップダウンから一致するユーザープロパティを選択します。
  7. User Property Check のボックスをチェックする場合は、User property ドロップダウンからユーザープロパティを選択し、必要な値を設定します。
  8. Save をクリックします。
Trip エンティティの Permissions ページ。権限の問題が検出されたという警告の下にルールの表があり、All Users は作成、更新、削除ができ、Creator Only は読み取りができます

データの権限を管理する

人が任意の 1 つのルールに一致すると、アクセスが許可されます。追加の Entity-User Field Comparison または User Property Check 行を追加するには、パネルの下部にある Add rule をクリックします。アクションをカバーする唯一のルールを削除することはできません。最初にそのアクションの別のルールを追加してから、削除したいものの選択を解除してください。
ページ下部の Generated JSON (Preview) セクションには、ルールが Base44 が舞台裏で使用する技術形式にどう変換されるかが表示されます。権限エディタを使用するためにそれを理解する必要はありませんが、開発者が権限設定の共有を依頼した場合や、どのルールが正確に有効かを確認したい場合に役立ちます。

​
権限ルールタイプ

通常、ルールを手動で追加する必要はありません。AI はデータテーブルを作成するときに設定し、Permission recommendations パネルは何かがおかしいときに修正を提案します。このセクションは、推奨を適用する前に各ルールが何をするかを理解したい場合や、特定の何かを微調整する必要がある場合のためにあります。
すでに特定のルールがあるアクションに All Users を有効にすると、それらのルールがクリアされる前に確認ダイアログが表示されます。アクションに All Users がアクティブな状態で特定のルールを有効にすると、All Users は自動的に削除されます。

​
Entity-User Field Comparison の仕組み

このルールは、レコードのフィールドがサインインしている人のアカウントのプロパティに一致するかどうかをチェックします。一致する場合、アクセスが許可されます。 2 つのことを設定します:
  • Entity field: このデータテーブルにすでに存在するフィールドの名前。フィールド名を見つけるには、Dashboard に移動し、Data の下のテーブルをクリックして、そこにリストされている列を見てください。表示されているとおりにフィールド名を入力します。例: assigned_to や owner_email。
  • User field: 比較する、サインインしている人のアカウントからのプロパティで、ドロップダウンから選択します。例: メールアドレス。
例: タスクが属する人のメールを保存する assigned_to フィールドを持つ Tasks テーブルがあります。Entity field を assigned_to に、User field を email に設定します。これで、各人は自分に割り当てられたタスクのみを見ます。 複数のフィールドペアで一致させる必要がある場合は、複数の Entity-User Field Comparison 行を追加できます。

​
User Property Check の仕組み

このルールは、サインインしている人のアカウントのプロパティをチェックして、設定した値に一致する場合にのみアクセスを許可します。 2 つのことを設定します:
  • User property: チェックするアカウントフィールド。例: User Role、User Email、または Full Name。
  • Required value: 一致する必要がある値。User Role の場合、ドロップダウンから Admin または User を選択できます。他のフィールドの場合は、値を直接入力します。
例: 管理者のみがレコードを削除できるようにしたい。User property を User Role に、Required value を Admin に設定します。 異なるプロパティや値のための複数の User Property Check 行を追加できます。

​
権限推奨事項を適用する

AI が現在の設定で潜在的なリスクを検出すると、データテーブルページに直接 Permission risks detected バナーが表示されます。リスクのサマリーと推奨される修正を表示します。次の 2 つの方法で操作できます:
  • Fix をクリックして推奨事項に直接移動し、1 ステップで適用します。
  • More details をクリックして完全な Permission recommendations パネルを開き、適用する前に変更をレビューします。
Trip テーブルで囲まれた Permissions issues detected バナー。その下に Create、Read、Update、Delete にチェックが入った All Users のルールがあります

テーブルの権限の問題

Permission recommendations パネルには 2 つのセクションが表示されます。Risk セクションには、現在のルールと、それらが意図しない人々にデータを露出する可能性がある理由が説明されます。Recommended rules セクションには、推奨される置き換えと、それらが施行するものの平易な言葉での説明が表示されます。 Apply recommendations をクリックして現在のルールを推奨されるルールに置き換えるか、Cancel をクリックしてパネルを閉じて既存のルールを維持します。推奨事項を適用した後にルールを手動で編集することもできます。
Permission recommendations ダイアログ。All Users が作成、読み取り、更新、削除できるリスクの表の下に、読み取り、更新、削除を Creator Only と管理者に制限する推奨ルールがあります

権限推奨事項パネル

​
権限をテストする

テーブルの権限を変更したら、テストして各ユーザーが必要な範囲にだけアクセスできることを確認します。テストでは、選んだユーザーとしてアプリのプレビューが開くため、そのユーザーから見たルールを確認できます。テスト中に行った変更はそのユーザーのデータに保存されるため、可能であればサンプルのユーザーでテストします。 権限をテストするには:
  1. アプリエディタで Dashboard をクリックします。
  2. Data の下で、テストするテーブルをクリックします。
  3. ページ右上の Permissions をクリックします。
  4. Edit をクリックし、ルールを変更して Save をクリックします。詳しくは 権限を手動でカスタマイズする を参照してください。
  5. Edit の横にある Test Permissions in preview をクリックします。このテーブルを使うページでアプリのプレビューが開き、ユーザーのリストがすでに開いた状態になります。
    テーブルの Permissions ページにある Current permissions カード。Edit の横の Test Permissions in preview にカーソルが合っています

    保存後に権限をテストする

  6. ユーザーを選択して、そのユーザーとしてアプリを表示します。
  7. そのユーザーが表示および操作できる内容を確認します。比較するには、You’re acting as の横にあるドロップダウンから別のユーザーを選択します。
  8. 完了したら Exit mode をクリックします。
テーブルの権限はいつでもテストできます。Data ページでテーブルのカードにある More actions アイコンをクリックし、Test Permissions in preview を選択します。詳しくは ユーザーとしてアプリをテストする を参照してください。

​
アプリタイプ別の権限の例

アプリの権限をセットアップする方法が分からない? これらの一般的なシナリオを出発点として使用してください。AI チャットに設定をレビューして適切なルールを提案するように依頼することもできます。
家族の買い物リストや共有家庭管理ツールなど、信頼できる少数の人々のグループが同じアプリを使用します。
  • アプリの可視性: Private。アクセスが必要な人々を招待します。
  • ログインを要求: はい。
  • 権限: 全員が平等に共有するデータには、制限は必要ありません。個人的なメモやリマインダーなど、各人に個別に属するデータには、Read、Update、Delete に Creator Only を使用して、各人が自分が作成したレコードのみにアクセスできるようにします。
誰でもサイトを訪問できますが、送信した応募はあなたまたはチームのみに表示される必要があります。
  • アプリの可視性: Public。
  • ログインを要求: いいえ。
  • 権限: フォーム送信テーブルでは、Create に All Users を使用して誰でも送信できるようにします。Read、Update、Delete には、管理者ロールに制限された User Property Check を使用して、チームのみが受信したメッセージを表示および管理できるようにします。
チームや会社が内部でアプリを使用し、一部のデータはマネージャーや特定のロールのみに表示される必要があります。
  • アプリの可視性: Workspace。
  • ログインを要求: はい。
  • 権限: 給与データやパフォーマンスレビューなどの機密テーブルをマネージャーロールに制限するには、User Property Check を使用します。お知らせや共有リソースなどの一般的なコンテンツには、Read に All Users を使用してチーム全体が表示できるようにします。
各人はログインして自分のデータを管理します。彼らは自分のレコードのみを見るべきで、他の誰かのレコードは決して見ないべきです。
  • アプリの可視性: オープンサインアップが必要か、招待のみが必要かに応じて、Public または Workspace。
  • ログインを要求: はい。
  • 権限: すべての個人データテーブルで、Read、Update、Delete に Creator Only を使用します。これにより、各人は自分が作成したレコードのみにアクセスできることが保証されます。
誰でもコンテンツを参照できますが、編集者または管理者のみが何かを追加または変更できます。
  • アプリの可視性: Public。
  • ログインを要求: いいえ、特定のコンテンツをゲートしたい場合を除きます。
  • 権限: Read に All Users を使用して、誰でもコンテンツを表示できるようにします。Create、Update、Delete には、編集者または管理者ロールに制限された User Property Check を使用して、チームのみがコンテンツを管理できるようにします。
異なる会社、学校、または部門がそれぞれアプリを使用しますが、データは完全に互いに分離されている必要があります。
  • アプリの可視性: セットアップに応じて Public または Workspace。
  • ログインを要求: はい。
  • 権限: 各レコードのフィールドをサインインしている人のアカウントのプロパティに一致させるには、Entity-User Field Comparison を使用します。例えば、各レコードに company_id フィールドがあり、各ユーザーアカウントに一致する company_id プロパティがある場合、Entity field を company_id に、User field を company_id に設定します。各人は自分の会社に属するレコードのみを見ます。グループ内の管理者アクセスには、管理者ロールに対する User Property Check と組み合わせます。

​
FAQ

いいえ。Base44 は、データテーブルを作成するときに自動的に権限をセットアップします。平易な言葉でいつでも AI チャットにそれらを更新するように依頼でき、または各テーブルの Permissions ページから手動で調整できます。公開する前に、セキュリティスキャンを実行してすべてが正しく見えることを確認する価値があります。
影響を受けるテーブルをダッシュボードで開き、その Permissions ページを確認します。Permission risks detected バナーがある場合は、Fix をクリックして推奨されるルールを適用するか、最初にレビューするには More details をクリックします。Security タブからセキュリティスキャンを実行して、アプリ全体の問題の完全な概要を確認することもでき、または問題を AI チャットに説明して修正を依頼できます。変更を加えたら、テーブルの Permissions ページで Test Permissions in preview をクリックします。さまざまなユーザーとしてアプリを表示し、アクセスが期待どおりに動作することを確認します。
はい、変更はすぐに反映されます。変更を保存したら、テーブルの Permissions ページで Test Permissions in preview をクリックします。さまざまなユーザーとしてアプリを表示し、アクセスが期待どおりに動作することを確認します。
はい。User テーブルにカスタムフィールド (department や access_level など) を追加して、マネージャーやビューアなどの値を定義します。次に、そのフィールドに User Property Check ルールを使用して、各ロールに適切なレベルのアクセスを与えます。AI チャットに設定するように依頼できます。
いいえ。権限は、個々のフィールドではなくデータテーブル全体に適用されます。テーブルから返されるデータを制限する必要がある場合、これはバックエンド関数を介して行えます。これにより、アプリに到達する前にデータをフィルタリングまたは変換できます。AI チャットにこのセットアップを支援するように依頼できます。
権限が、高度な演算子を使用する条件など、ビジュアルエディタが表現するには複雑すぎるルールでセットアップされている場合、エディタは JSON のみのビューにフォールバックします。JSON を直接編集することも、マトリックスのボックスをチェックして新しく開始することもできます。これにより、既存の設定を置き換える前に確認を求められます。
このページは AI を使用して翻訳されました。最も正確で最新の情報については、英語版 を参照してください。