Sécurité

Les entités prennent en charge deux niveaux de sécurité :

Sécurité au niveau ligne (RLS) : contrôle quels enregistrements les utilisateurs peuvent accéder.
Sécurité au niveau champ (FLS) : contrôle quels champs dans les enregistrements les utilisateurs peuvent accéder.

L’accès avec le rôle de service ignore ces règles : base44.asServiceRole contourne entièrement RLS et FLS, quelle que soit la configuration de l’entité. Vous n’avez donc pas besoin d’une règle d’administration correspondante pour lire ou écrire un enregistrement. Il n’est disponible que dans les fonctions backend hébergées par Base44, et votre fonction est responsable des contrôles d’accès nécessaires.

Types de permissions

Chaque niveau de sécurité a différentes permissions que vous pouvez définir. Pour chaque permission, vous définissez qui est autorisé à effectuer l’action.

Sécurité au niveau ligne (RLS)

create - Ajouter de nouveaux enregistrements
read - Voir les enregistrements
update - Modifier les enregistrements
delete - Supprimer les enregistrements

Sécurité au niveau champ (FLS)

read - Voir le champ
write - Créer ou modifier le champ

Valeurs de permission

Chaque permission accepte l’une des valeurs suivantes :

true - Autoriser tous les utilisateurs
false - Bloquer tous les utilisateurs
{<condition>} - Autoriser les utilisateurs correspondant à la condition

Différence entre les lectures et les écritures refusées

Les lectures refusées se comportent comme si les données n’existaient pas. Elles ne révèlent donc pas ce qui s’y trouve. Les écritures refusées lèvent une erreur. Une modification bloquée n’échoue donc jamais silencieusement.

Opération	Quand une règle la refuse
`list()`, `filter()`	Renvoie un résultat vide, comme si rien ne correspondait. Aucune erreur n’est levée.
`get()`	Lève une erreur « introuvable » (HTTP 404), que l’enregistrement existe ou non.
`create()`, `update()`	Lève une erreur d’autorisation (HTTP 403).

Syntaxe de condition

Lorsque vous utilisez {<condition>} comme valeur de permission, vous pouvez définir des règles qui vérifient les attributs ou les rôles utilisateur.

Une condition qui référence {{user.*}} ou utilise user_condition nécessite un appelant authentifié. Un appelant anonyme n’a pas d’utilisateur à comparer. La règle le bloque donc directement au lieu d’être évaluée comme fausse.

1. Comparaison entité-utilisateur Comparez les champs d’enregistrement aux valeurs de l’utilisateur actuel. Champs d’entité que vous pouvez référencer :

created_by - E-mail de l’utilisateur qui a créé l’enregistrement
created_by_id - ID de l’utilisateur qui a créé l’enregistrement
entity_name - Nom du type d’entité
app_id - ID de l’application
environment - Soit prod soit dev
is_sample - Si c’est un échantillon de données
is_deleted - Indicateur de suppression douce
deleted_date - Quand il a été supprimé
data.* - Tout champ des propriétés du schéma de votre entité

Variables de modèle pour les valeurs utilisateur :

{{user.email}} - E-mail de l’utilisateur
{{user.id}} - ID de l’utilisateur
{{user.role}} - Rôle de l’utilisateur
{{user.data.*}} - Champs utilisateur supplémentaires que vous définissez

Exemple :

{"created_by": "{{user.email}}"}
{"data.department": "{{user.data.department}}"}
{"data.status": "approved"}

2. Vérification de condition utilisateur Vérifiez les propriétés utilisateur directement en utilisant user_condition. Champs utilisateur que vous pouvez vérifier :

email - E-mail de l’utilisateur
id - ID de l’utilisateur
role - Rôle de l’utilisateur
data.* - Champs utilisateur personnalisés

Exemple :

{"user_condition": {"role": "admin"}}
{"user_condition": {"data.level": "senior"}}

3. Conditions complexes Combinez plusieurs conditions en utilisant des opérateurs. Opérateurs pris en charge : $or, $and, $nor, $in, $nin, $all Exemple :

{
  "$or": [
    {"created_by": "{{user.email}}"},
    {"user_condition": {"role": "admin"}}
  ]
}

Exemple de sécurité au niveau ligne (RLS)

Ajoutez rls au niveau de l’entité :

{
  "name": "task",
  "type": "object",
  "properties": {...},
  "rls": {
    "create": true,
    "read": {"created_by": "{{user.email}}"},
    "update": {"created_by": "{{user.email}}"},
    "delete": {"user_condition": {"role": "admin"}}
  }
}

Exemple de sécurité au niveau champ (FLS)

Ajoutez rls aux propriétés de champs individuels :

{
  "properties": {
    "salary": {
      "type": "number",
      "rls": {
        "read": {"user_condition": {"role": "admin"}},
        "write": {"user_condition": {"role": "admin"}}
      }
    }
  }
}

Exemple complet avec sécurité

Voici un schéma d’entité avec RLS et FLS :

{
  "name": "Task",
  "type": "object",
  "title": "Task",
  "description": "A task item with priority, due date, and completion status",
  "properties": {
    "title": {
      "type": "string",
      "minLength": 1,
      "maxLength": 200
    },
    "description": {
      "type": "string",
      "maxLength": 1000
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"],
      "default": "medium"
    },
    "completed": {
      "type": "boolean",
      "default": false
    },
    "due_date": {
      "type": "string",
      "format": "date"
    },
    "tags": {
      "type": "array",
      "items": {"type": "string"}
    },
    "internal_notes": {
      "type": "string",
      "rls": {
        "read": {"user_condition": {"role": "admin"}},
        "write": {"user_condition": {"role": "admin"}}
      }
    }
  },
  "required": ["title"],
  "rls": {
    "create": true,
    "read": {"created_by": "{{user.email}}"},
    "update": {"created_by": "{{user.email}}"},
    "delete": {"created_by": "{{user.email}}"}
  }
}

Déploiement des règles de sécurité

Les règles de sécurité font partie de votre schéma d’entité. Après avoir ajouté ou mis à jour des règles de sécurité, déployez en utilisant entities push. Les règles de sécurité sont également déployées automatiquement lorsque vous exécutez la commande deploy pour déployer l’ensemble de votre projet.

Voir aussi

Présentation des entités : apprenez la configuration du schéma de base de données
Schémas d’entités : définissez la structure de votre entité
Schéma utilisateur : entité intégrée spéciale pour l’authentification utilisateur
Accès aux données avec le rôle de service : lisez et écrivez des données sans que les règles d’accès s’appliquent
Structure du projet : comment les schémas d’entités s’intègrent dans votre projet

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

Aperçu

Démarrages rapides

Projet

Outils de développement IA

Ressources

Types de permissions

Sécurité au niveau ligne (RLS)

Sécurité au niveau champ (FLS)

Valeurs de permission

Différence entre les lectures et les écritures refusées

Syntaxe de condition

Exemple de sécurité au niveau ligne (RLS)

Exemple de sécurité au niveau champ (FLS)

Exemple complet avec sécurité

Déploiement des règles de sécurité

Voir aussi

​Types de permissions

​Sécurité au niveau ligne (RLS)

​Sécurité au niveau champ (FLS)

​Valeurs de permission

​Différence entre les lectures et les écritures refusées

​Syntaxe de condition

​Exemple de sécurité au niveau ligne (RLS)

​Exemple de sécurité au niveau champ (FLS)

​Exemple complet avec sécurité

​Déploiement des règles de sécurité

​Voir aussi

Types de permissions

Sécurité au niveau ligne (RLS)

Sécurité au niveau champ (FLS)

Valeurs de permission

Différence entre les lectures et les écritures refusées

Syntaxe de condition

Exemple de sécurité au niveau ligne (RLS)

Exemple de sécurité au niveau champ (FLS)

Exemple complet avec sécurité

Déploiement des règles de sécurité

Voir aussi