Cette page fait partie d’une compétence d’agent de code IA et est écrite pour les agents, pas pour les humains. Pour la documentation Base44 lisible par un humain, consultez la documentation développeur.

Exemples RLS

Modèles pratiques de sécurité au niveau ligne pour les types d’applications courants. Important : RLS Base44 prend en charge :

Opérateurs logiques : $or, $and, $nor pour combiner des conditions
Opérateurs de champ (pour les champs data.*) : $in, $nin, $ne, $all
user_condition : égalité uniquement (pas d’opérateurs)

Sommaire

Modèles simples (JSON Schema)
Utilisation des opérateurs
Exemples de sécurité au niveau champ
Modèles complexes (UI du tableau de bord ou backend)
Bonnes pratiques

Modèles simples (JSON Schema)

Ces modèles fonctionnent avec le format RLS de schéma JSON.

Application Todo — accès réservé au propriétaire

Les utilisateurs voient et gèrent uniquement leurs propres tâches.

{
  "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}}" }
  }
}

Formulaire de contact — création publique, lecture admin uniquement

Tout le monde peut soumettre, seuls les administrateurs peuvent voir les soumissions.

{
  "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" } }
  }
}

Profil utilisateur — auto-gestion

Les utilisateurs ne peuvent accéder qu’à leur propre profil.

{
  "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}}" }
  }
}

Données de département — accès au même département

Les utilisateurs ne peuvent voir que les enregistrements de leur département.

{
  "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" } }
  }
}

Abonnement — géré par l’admin, lisible par l’utilisateur via le champ e-mail

{
  "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" } }
  }
}

Note : ce modèle permet aux utilisateurs de lire uniquement leur propre abonnement. Les administrateurs doivent utiliser l’UI du tableau de bord pour configurer un accès en lecture supplémentaire pour eux-mêmes.

Données privées — propriétaire uniquement

{
  "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}}" }
  }
}

Lecture publique, écriture authentifiée

Tout le monde peut lire, seuls les utilisateurs connectés peuvent créer/modifier leurs propres enregistrements.

{
  "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}}" }
  }
}

Utilisation des opérateurs

Opérateurs logiques

Combinez plusieurs conditions avec $or, $and ou $nor : Accès propriétaire OU admin :

{
  "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" } }
  }
}

Plusieurs rôles avec $or :

{
  "rls": {
    "read": {
      "$or": [
        { "user_condition": { "role": "admin" } },
        { "user_condition": { "role": "manager" } },
        { "user_condition": { "role": "hr" } }
      ]
    }
  }
}

Opérateurs de champ pour les champs data.*

Utilisez $in, $nin, $ne, $all pour comparer les champs de données d’entité : Accès basé sur des tags ($in) :

{
  "rls": {
    "read": {
      "data.category": { "$in": ["public", "shared"] }
    }
  }
}

Exclure certains statuts ($nin) :

{
  "rls": {
    "read": {
      "data.status": { "$nin": ["archived", "deleted"] }
    }
  }
}

Différent ($ne) :

{
  "rls": {
    "read": {
      "data.visibility": { "$ne": "private" }
    }
  }
}

Tous les tags doivent correspondre ($all) :

{
  "rls": {
    "read": {
      "data.required_tags": { "$all": ["approved", "reviewed"] }
    }
  }
}

Combiner opérateurs logiques et de champ

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

Exemples de sécurité au niveau champ

Contrôlez l’accès à des champs précis d’une entité.

Champ salaire sensible

{
  "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" } }
      }
    }
  }
}

Champs internes réservés aux admins

{
  "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
      }
    }
  }
}

Modèles complexes (UI du tableau de bord ou backend)

Certains modèles peuvent encore nécessiter l’UI du tableau de bord ou des fonctions backend.

Relations bidirectionnelles (par exemple, amitiés, matches)

Besoin : l’une ou l’autre des parties d’une relation doit avoir accès. Désormais possible avec $or :

{
  "rls": {
    "read": {
      "$or": [
        { "data.user_a_email": "{{user.email}}" },
        { "data.user_b_email": "{{user.email}}" }
      ]
    }
  }
}

Solutions alternatives :

Refonte d’entité : stocker deux enregistrements par relation (un pour chaque partie)
Fonction backend : interroger avec une logique personnalisée

Logique métier complexe

Besoin : l’accès dépend de plusieurs champs d’entité avec des conditions complexes. Limitation du JSON Schema : même si les opérateurs aident, une logique métier très complexe peut rester difficile à exprimer. Options de solution :

Fonction backend : implémenter une logique d’accès personnalisée
Combiner des règles plus simples : décomposer les règles complexes en règles plus simples au niveau entité et au niveau champ

Bonnes pratiques

Stratégie de sécurité

Utilisez une combinaison de RLS au niveau entité et de sécurité au niveau champ :

Type de données	Approche	Exemple
Modifiables par l’utilisateur	RLS entité : propriétaire uniquement	UserProfile avec vérification `created_by`
Champs sensibles	RLS au niveau champ	Champ salaire avec vérification du rôle HR
Accès multi-rôle	`$or` avec user_condition	Accès Admin OU Manager
Accès conditionnel	Opérateurs de champ	`$in`, `$ne` sur les champs data
Contenu public	RLS entité : `read: true`	PublicPost
Contenu privé	RLS entité : propriétaire uniquement	PrivateNote

Quand utiliser chaque approche

Besoin	Approche
Condition unique (propriétaire, admin, département)	RLS JSON Schema
Plusieurs conditions OR/AND	RLS JSON Schema avec `$or`/`$and`
Vérifications de valeurs de champs avec `$in`/`$ne`/etc.	RLS JSON Schema pour les champs `data.*`
Contrôle d’accès au niveau champ	FLS JSON Schema (`rls` au niveau champ)
Opérateurs de comparaison complexes (`$gt`, `$lt`)	Fonctions backend
Logique métier très complexe	Fonctions backend

Modèles de rôle courants

Rôle	Accès typique
`admin`	Accès complet à tous les enregistrements
`moderator`	Accès lecture/mise à jour, suppression limitée
`manager`	Accès à l’échelle du département
`user`	Ses propres enregistrements uniquement

Résumé des opérateurs pris en charge

Opérateur	Pris en charge	Remarques
`$or`	Oui	Combiner plusieurs conditions
`$and`	Oui	Toutes les conditions doivent correspondre
`$nor`	Oui	Aucune des conditions ne correspond
`$in`	Oui	Pour les champs `data.*` uniquement
`$nin`	Oui	Pour les champs `data.*` uniquement
`$ne`	Oui	Pour les champs `data.*` uniquement
`$all`	Oui	Pour les champs `data.*` uniquement
`$gt`, `$lt`, `$gte`, `$lte`	Non	Utilisez des fonctions backend
`$regex`	Non	Utilisez des fonctions backend

Résumé des limitations

Non pris en charge	Alternative
Opérateurs sur `user_condition`	Utilisez l’égalité uniquement pour les vérifications utilisateur
Opérateurs de comparaison (`$gt`, `$lt`)	Fonctions backend
Correspondance regex (`$regex`)	Fonctions backend
Relations inter-entités	Fonctions backend

Cette page a été traduite à l’aide de l’IA. Pour les informations les plus précises et à jour, consultez la version anglaise.

​Exemples RLS

​Sommaire

​Modèles simples (JSON Schema)

​Application Todo — accès réservé au propriétaire

​Formulaire de contact — création publique, lecture admin uniquement

​Profil utilisateur — auto-gestion

​Données de département — accès au même département

​Abonnement — géré par l’admin, lisible par l’utilisateur via le champ e-mail

​Données privées — propriétaire uniquement

​Lecture publique, écriture authentifiée

​Utilisation des opérateurs

​Opérateurs logiques

​Opérateurs de champ pour les champs data.*

​Combiner opérateurs logiques et de champ

​Exemples de sécurité au niveau champ

​Champ salaire sensible

​Champs internes réservés aux admins

​Modèles complexes (UI du tableau de bord ou backend)

​Relations bidirectionnelles (par exemple, amitiés, matches)

​Logique métier complexe

​Bonnes pratiques

​Stratégie de sécurité

​Quand utiliser chaque approche

​Modèles de rôle courants

​Résumé des opérateurs pris en charge

​Résumé des limitations

Exemples RLS

Sommaire

Modèles simples (JSON Schema)

Application Todo — accès réservé au propriétaire

Formulaire de contact — création publique, lecture admin uniquement

Profil utilisateur — auto-gestion

Données de département — accès au même département

Abonnement — géré par l’admin, lisible par l’utilisateur via le champ e-mail

Données privées — propriétaire uniquement

Lecture publique, écriture authentifiée

Utilisation des opérateurs

Opérateurs logiques

Opérateurs de champ pour les champs data.*

Combiner opérateurs logiques et de champ

Exemples de sécurité au niveau champ

Champ salaire sensible

Champs internes réservés aux admins

Modèles complexes (UI du tableau de bord ou backend)

Relations bidirectionnelles (par exemple, amitiés, matches)

Logique métier complexe

Bonnes pratiques

Stratégie de sécurité

Quand utiliser chaque approche

Modèles de rôle courants

Résumé des opérateurs pris en charge

Résumé des limitations