Sicherheit

Entitäten unterstützen zwei Sicherheitsebenen:

Row Level Security (RLS): Steuert, auf welche Datensätze Benutzer zugreifen können.
Field Level Security (FLS): Steuert, auf welche Felder innerhalb von Datensätzen Benutzer zugreifen können.

Zugriff über die Service-Rolle umgeht diese Regeln: base44.asServiceRole umgeht RLS und FLS vollständig, egal wie die Entität konfiguriert ist. Du brauchst also keine passende Admin-Regel, damit sie einen Datensatz lesen oder schreiben kann. Sie ist nur in von Base44 gehosteten Backend-Funktionen verfügbar, und deine Funktion ist für alle nötigen Zugriffsprüfungen selbst verantwortlich.

Berechtigungstypen

Jede Sicherheitsebene hat unterschiedliche Berechtigungen, die du setzen kannst. Für jede Berechtigung definierst du, wer die Aktion ausführen darf.

Row Level Security (RLS)

create – Neue Datensätze hinzufügen
read – Datensätze ansehen
update – Datensätze ändern
delete – Datensätze entfernen

Field Level Security (FLS)

read – Das Feld ansehen
write – Das Feld erstellen oder ändern

Berechtigungswerte

Jede Berechtigung akzeptiert einen der folgenden Werte:

true – Allen Benutzern erlauben
false – Allen Benutzern verbieten
{<condition>} – Benutzer erlauben, die der Bedingung entsprechen

Wie sich abgelehnte Lese- und Schreibvorgänge unterscheiden

Abgelehnte Lesevorgänge verhalten sich, als gäbe es die Daten nicht. So verraten sie nicht, was vorhanden ist. Abgelehnte Schreibvorgänge werfen einen Fehler, damit eine blockierte Änderung nie still fehlschlägt.

Vorgang	Wenn eine Regel ihn ablehnt
`list()`, `filter()`	Gibt ein leeres Ergebnis zurück, genau wie ohne Treffer. Es wird kein Fehler geworfen.
`get()`	Wirft einen Not-found-Fehler (HTTP 404), egal ob der Datensatz existiert oder nicht.
`create()`, `update()`	Wirft einen Berechtigungsfehler (HTTP 403).

Bedingungssyntax

Wenn du {<condition>} als Berechtigungswert verwendest, kannst du Regeln definieren, die Benutzerattribute oder -rollen prüfen.

Eine Bedingung, die {{user.*}} referenziert oder user_condition nutzt, erfordert einen authentifizierten Aufrufer. Ein anonymer Aufrufer hat keinen Benutzer zum Vergleichen. Die Regel blockiert ihn daher direkt, statt als false ausgewertet zu werden.

1. Entity-zu-Benutzer-Vergleich Vergleiche Datensatzfelder mit den Werten des aktuellen Benutzers. Entity-Felder, die du referenzieren kannst:

created_by – E-Mail des Benutzers, der den Datensatz erstellt hat
created_by_id – ID des Benutzers, der den Datensatz erstellt hat
entity_name – Name des Entitätstyps
app_id – App-ID
environment – Entweder prod oder dev
is_sample – Ob es sich um Beispieldaten handelt
is_deleted – Soft-Delete-Flag
deleted_date – Wann er gelöscht wurde
data.* – Jedes Feld aus den properties deines Entity-Schemas

Template-Variablen für Benutzerwerte:

{{user.email}} – E-Mail des Benutzers
{{user.id}} – ID des Benutzers
{{user.role}} – Rolle des Benutzers
{{user.data.*}} – Zusätzliche von dir definierte Benutzerfelder

Beispiel:

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

2. Prüfung der Benutzerbedingung Prüfe Benutzereigenschaften direkt mit user_condition. Benutzerfelder, die du prüfen kannst:

email – E-Mail des Benutzers
id – ID des Benutzers
role – Rolle des Benutzers
data.* – Eigene Benutzerfelder

Beispiel:

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

3. Komplexe Bedingungen Kombiniere mehrere Bedingungen mit Operatoren. Unterstützte Operatoren: $or, $and, $nor, $in, $nin, $all Beispiel:

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

Beispiel für Row Level Security (RLS)

Füge rls auf Entity-Ebene hinzu:

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

Beispiel für Field Level Security (FLS)

Füge rls zu einzelnen Feld-Eigenschaften hinzu:

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

Vollständiges Beispiel mit Sicherheit

Hier ist ein Entity-Schema mit RLS und 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}}"}
  }
}

Sicherheitsregeln deployen

Sicherheitsregeln sind Teil deines Entity-Schemas. Nach dem Hinzufügen oder Aktualisieren von Sicherheitsregeln deploye sie mit entities push. Sicherheitsregeln werden außerdem automatisch deployed, wenn du den deploy-Befehl ausführst, um dein gesamtes Projekt zu deployen.

Siehe auch

Entitäten – Übersicht: Lerne mehr über die Datenbankschema-Konfiguration
Entity-Schemas: Definiere deine Entitätsstruktur
User-Schema: Spezielle eingebaute Entität für Benutzer-Authentifizierung
Datenzugriff über die Service-Rolle: Daten lesen und schreiben, ohne dass Zugriffsregeln gelten
Projektstruktur: Wie Entity-Schemas in dein Projekt passen

Diese Seite wurde mit KI übersetzt. Für die genauesten und aktuellsten Informationen siehe die englische Version.

Übersicht

Schnellstarts

Projekt

KI-Entwicklungstools

Ressourcen

Berechtigungstypen

Row Level Security (RLS)

Field Level Security (FLS)

Berechtigungswerte

Wie sich abgelehnte Lese- und Schreibvorgänge unterscheiden

Bedingungssyntax

Beispiel für Row Level Security (RLS)

Beispiel für Field Level Security (FLS)

Vollständiges Beispiel mit Sicherheit

Sicherheitsregeln deployen

Siehe auch

​Berechtigungstypen

​Row Level Security (RLS)

​Field Level Security (FLS)

​Berechtigungswerte

​Wie sich abgelehnte Lese- und Schreibvorgänge unterscheiden

​Bedingungssyntax

​Beispiel für Row Level Security (RLS)

​Beispiel für Field Level Security (FLS)

​Vollständiges Beispiel mit Sicherheit

​Sicherheitsregeln deployen

​Siehe auch

Berechtigungstypen

Row Level Security (RLS)

Field Level Security (FLS)

Berechtigungswerte

Wie sich abgelehnte Lese- und Schreibvorgänge unterscheiden

Bedingungssyntax

Beispiel für Row Level Security (RLS)

Beispiel für Field Level Security (FLS)

Vollständiges Beispiel mit Sicherheit

Sicherheitsregeln deployen

Siehe auch