Skip to main content
このページは AI コーディングエージェントスキルの一部で、人間ではなくエージェント向けに書かれています。人間向けの Base44 ドキュメントは デベロッパードキュメント を参照してください。

​
RLS の例

一般的なアプリケーションタイプ向けの実用的な行レベルセキュリティパターン。 重要: Base44 RLS がサポートするもの:
  • 論理演算子: 条件を組み合わせるための $or, $and, $nor
  • フィールド演算子 (data.* フィールド用): $in, $nin, $ne, $all
  • user_condition: 等価性のみ (演算子なし)

​
目次

​
シンプルなパターン (JSON Schema)

これらのパターンは JSON schema RLS フォーマットで動作します。

​
Todo アプリ - 所有者のみアクセス

ユーザーは自分のタスクのみを表示および管理できます。 
{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "description": { "type": "string" },
    "completed": { "type": "boolean" },
    "priority": { "type": "string", "enum": ["low", "medium", "high"] },
    "due_date": { "type": "string", "format": "date" }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

​
問い合わせフォーム - 公開作成、管理者のみ読み取り

誰でも送信可能、管理者のみが送信内容を閲覧可能。 
{
  "name": "ContactSubmission",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" },
    "message": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": { "user_condition": { "role": "admin" } },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

​
ユーザープロフィール - 自己管理

ユーザーは自分のプロフィールのみアクセスできます。 
{
  "name": "UserProfile",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "avatar_url": { "type": "string" },
    "bio": { "type": "string" },
    "preferences": { "type": "object" }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

​
部門データ - 同部門アクセス

ユーザーは自分の部門のレコードのみ閲覧できます。 
{
  "name": "DepartmentAnnouncement",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "department": { "type": "string" }
  },
  "rls": {
    "create": { "user_condition": { "role": "manager" } },
    "read": { "data.department": "{{user.data.department}}" },
    "update": { "user_condition": { "role": "manager" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

​
サブスクリプション - 管理者管理、email フィールド経由でユーザーが読み取り可能

{
  "name": "Subscription",
  "type": "object",
  "properties": {
    "user_email": { "type": "string" },
    "tier": { "type": "string", "enum": ["free", "basic", "pro", "enterprise"] },
    "credits": { "type": "number" },
    "renewal_date": { "type": "string", "format": "date" }
  },
  "rls": {
    "create": { "user_condition": { "role": "admin" } },
    "read": { "data.user_email": "{{user.email}}" },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}
注意: このパターンではユーザーは自分のサブスクリプションのみ読み取り可能です。管理者は自身の追加の読み取りアクセスを構成するためにダッシュボード UI を使用する必要があります。

​
プライベートデータ - 所有者のみ

{
  "name": "PrivateNotes",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "tags": { "type": "array", "items": { "type": "string" } }
  },
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

​
公開読み取り、認証書き込み

誰でも読み取り可能、ログイン済みユーザーのみが自分のレコードを作成/編集可能。 
{
  "name": "BlogPost",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" },
    "author_email": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": true,
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

​
演算子の使用

​
論理演算子

$or、$and、または $nor を使用して複数の条件を組み合わせます: 所有者 OR 管理者アクセス: 
{
  "name": "Document",
  "type": "object",
  "properties": {
    "title": { "type": "string" },
    "content": { "type": "string" }
  },
  "rls": {
    "create": true,
    "read": {
      "$or": [
        { "created_by": "{{user.email}}" },
        { "user_condition": { "role": "admin" } }
      ]
    },
    "update": {
      "$or": [
        { "created_by": "{{user.email}}" },
        { "user_condition": { "role": "admin" } }
      ]
    },
    "delete": { "user_condition": { "role": "admin" } }
  }
}
$or で複数ロール: 
{
  "rls": {
    "read": {
      "$or": [
        { "user_condition": { "role": "admin" } },
        { "user_condition": { "role": "manager" } },
        { "user_condition": { "role": "hr" } }
      ]
    }
  }
}

​
data.* フィールドのフィールド演算子

エンティティデータフィールドの比較には $in、$nin、$ne、$all を使用します: タグに基づくアクセス ($in): 
{
  "rls": {
    "read": {
      "data.category": { "$in": ["public", "shared"] }
    }
  }
}
特定のステータスを除外 ($nin): 
{
  "rls": {
    "read": {
      "data.status": { "$nin": ["archived", "deleted"] }
    }
  }
}
等しくない ($ne): 
{
  "rls": {
    "read": {
      "data.visibility": { "$ne": "private" }
    }
  }
}
すべてのタグが一致する必要 ($all): 
{
  "rls": {
    "read": {
      "data.required_tags": { "$all": ["approved", "reviewed"] }
    }
  }
}

​
論理演算子とフィールド演算子の組み合わせ

{
  "rls": {
    "read": {
      "$and": [
        { "data.status": { "$ne": "draft" } },
        {
          "$or": [
            { "created_by": "{{user.email}}" },
            { "data.visibility": "public" }
          ]
        }
      ]
    }
  }
}

​
フィールドレベルセキュリティの例

エンティティ内の特定フィールドへのアクセスを制御します。

​
機密の給与フィールド

{
  "name": "Employee",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "email": { "type": "string", "format": "email" },
    "salary": {
      "type": "number",
      "description": "Annual salary",
      "rls": {
        "read": { "user_condition": { "role": "hr" } },
        "write": { "user_condition": { "role": "hr" } }
      }
    },
    "performance_notes": {
      "type": "string",
      "description": "Manager notes",
      "rls": {
        "read": {
          "$or": [
            { "user_condition": { "role": "manager" } },
            { "user_condition": { "role": "hr" } }
          ]
        },
        "write": { "user_condition": { "role": "manager" } }
      }
    }
  }
}

​
管理者のみの内部フィールド

{
  "name": "Order",
  "type": "object",
  "properties": {
    "order_number": { "type": "string" },
    "total": { "type": "number" },
    "internal_notes": {
      "type": "string",
      "description": "Internal processing notes",
      "rls": {
        "read": { "user_condition": { "role": "admin" } },
        "write": { "user_condition": { "role": "admin" } }
      }
    },
    "profit_margin": {
      "type": "number",
      "description": "Profit margin percentage",
      "rls": {
        "read": { "user_condition": { "role": "admin" } },
        "write": false
      }
    }
  }
}

​
複雑なパターン (ダッシュボード UI またはバックエンド)

一部のパターンは依然としてダッシュボード UI またはバックエンド関数を必要とする場合があります。

​
双方向のリレーション (例: 友達関係、マッチ)

要件: リレーションのいずれかの当事者がアクセスできる必要があります。 現在は $or で可能: 
{
  "rls": {
    "read": {
      "$or": [
        { "data.user_a_email": "{{user.email}}" },
        { "data.user_b_email": "{{user.email}}" }
      ]
    }
  }
}
代替ソリューション:
  1. エンティティ再設計: リレーションごとに 2 つのレコードを保存 (各当事者に 1 つ)
  2. バックエンド関数: カスタムロジックでクエリ

​
複雑なビジネスロジック

要件: アクセスが複雑な条件を持つ複数のエンティティフィールドに依存します。 JSON Schema の制限: 演算子が役立ちますが、非常に複雑なビジネスロジックはまだ表現が難しい場合があります。 解決策のオプション:
  1. バックエンド関数: カスタムアクセスロジックを実装
  2. より単純なルールを組み合わせる: 複雑なルールをより単純なエンティティレベルおよびフィールドレベルのルールに分解

​
ベストプラクティス

​
セキュリティ戦略

エンティティレベル RLS とフィールドレベルセキュリティを組み合わせて使用します:
データ型アプローチ例
ユーザー編集可能Entity RLS: 所有者のみcreated_by チェック付き UserProfile
機密フィールドフィールドレベル RLSHR ロールチェック付き Salary フィールド
マルチロールアクセスuser_condition と $orAdmin OR Manager アクセス
条件付きアクセスフィールド演算子data フィールドで $in, $ne
公開コンテンツEntity RLS: read: truePublicPost
プライベートコンテンツEntity RLS: 所有者のみPrivateNote

​
各アプローチをいつ使うか

要件アプローチ
単一条件 (owner, admin, department)JSON Schema RLS
複数の OR/AND 条件$or/$and を使った JSON Schema RLS
$in/$ne/等でのフィールド値チェックdata.* フィールド用の JSON Schema RLS
フィールドレベルアクセス制御JSON Schema FLS (フィールドレベル rls)
複雑な比較演算子 ($gt, $lt)バックエンド関数
非常に複雑なビジネスロジックバックエンド関数

​
一般的なロールパターン

ロール典型的なアクセス
adminすべてのレコードへのフルアクセス
moderator読み取り/更新アクセス、限定削除
manager部門スコープのアクセス
user自分のレコードのみ

​
サポートされる演算子のまとめ

演算子サポート注意事項
$orはい複数条件を組み合わせ
$andはいすべての条件が一致する必要
$norはいいずれの条件も一致しない
$inはいdata.* フィールドのみ
$ninはいdata.* フィールドのみ
$neはいdata.* フィールドのみ
$allはいdata.* フィールドのみ
$gt, $lt, $gte, $lteいいえバックエンド関数を使用
$regexいいえバックエンド関数を使用

​
制限のまとめ

未サポート代替
user_condition の演算子ユーザーチェックには等価性のみ使用
比較演算子 ($gt, $lt)バックエンド関数
正規表現マッチング ($regex)バックエンド関数
エンティティ間のリレーションバックエンド関数
このページは AI を使用して翻訳されました。最も正確で最新の情報については、英語版 を参照してください。