このページは 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}}" }
      ]
    }
  }
}

代替ソリューション:

エンティティ再設計: リレーションごとに 2 つのレコードを保存 (各当事者に 1 つ)
バックエンド関数: カスタムロジックでクエリ

複雑なビジネスロジック

要件: アクセスが複雑な条件を持つ複数のエンティティフィールドに依存します。 JSON Schema の制限: 演算子が役立ちますが、非常に複雑なビジネスロジックはまだ表現が難しい場合があります。 解決策のオプション:

バックエンド関数: カスタムアクセスロジックを実装
より単純なルールを組み合わせる: 複雑なルールをより単純なエンティティレベルおよびフィールドレベルのルールに分解

ベストプラクティス

セキュリティ戦略

エンティティレベル RLS とフィールドレベルセキュリティを組み合わせて使用します:

データ型	アプローチ	例
ユーザー編集可能	Entity RLS: 所有者のみ	`created_by` チェック付き UserProfile
機密フィールド	フィールドレベル RLS	HR ロールチェック付き Salary フィールド
マルチロールアクセス	user_condition と `$or`	Admin OR Manager アクセス
条件付きアクセス	フィールド演算子	data フィールドで `$in`, `$ne`
公開コンテンツ	Entity RLS: `read: true`	PublicPost
プライベートコンテンツ	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 を使用して翻訳されました。最も正確で最新の情報については、英語版を参照してください。

Getting started

Building your app

Designing your app

Managing app data

Adding logic to your app

Selling on your app

Using on mobile

Domains

Securing your app

Measuring your app

Growing your app's reach

Superagents

Integrations

RLS の例

RLS の例

目次

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

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

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

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

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

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

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

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

演算子の使用

論理演算子

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

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

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

機密の給与フィールド

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

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

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

複雑なビジネスロジック

ベストプラクティス

セキュリティ戦略

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

一般的なロールパターン

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

制限のまとめ

​RLS の例

​目次

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

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

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

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

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

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

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

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

​演算子の使用

​論理演算子

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

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

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

​機密の給与フィールド

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

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

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

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

​ベストプラクティス

​セキュリティ戦略

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

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

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

​制限のまとめ

RLS の例

目次

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

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

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

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

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

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

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

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

演算子の使用

論理演算子

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

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

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

機密の給与フィールド

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

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

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

複雑なビジネスロジック

ベストプラクティス

セキュリティ戦略

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

一般的なロールパターン

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

制限のまとめ