> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Workspaces

Grenzen Sie jeden benutzereigenen Datensatz mit workspaceId ab.

## Versuchen Sie es mit einem persönlichen Arbeitsplatz und einem Team

Ein Arbeitsbereich ist ein separater Container für Konten, Inhalte und Berechtigungen. Führen Sie zunächst die datenbankgestützte Anmeldung durch. Öffnen Sie das Dashboard und notieren Sie den aktuellen Arbeitsbereichsnamen. Verwenden Sie den Arbeitsbereich-Umschalter, um einen anderen Arbeitsbereich auszuwählen, zu dem Sie gehören. Die angezeigten Datensätze sollten sich in die Datensätze dieses Arbeitsbereichs ändern.

Um ein Team auszuprobieren, folgen Sie Organisationen, um eines zu erstellen, laden Sie eine zweite Test-E-Mail ein und nehmen Sie diese Einladung in einem privaten Browserfenster an, indem Sie mit diesem zweiten Konto angemeldet sind. Bestätigen Sie, dass ein Mitglied die Datensätze dieses Teams sieht, während ein unabhängiges Konto sie nicht öffnen kann. Besitzer- und Administratorrollen verwalten das Team; Der Mitgliederzugang ist enger. Halten Sie die beiden Konten während dieses Tests in separaten Browsersitzungen.

Wenn Sie einen Agenten bitten, eine neue Produkttabelle oder einen neuen Bildschirm hinzuzufügen, fordern Sie explizit workspaceId für jeden benutzereigenen Datensatz und serverseitige Mitgliedschaftsprüfungen für jeden Lese- und Schreibvorgang an. Eine Arbeitsbereichs-ID in einem URL identifiziert den Arbeitsbereich. es gewährt keinen Zugriff. Lassen Sie den Agenten ein unabhängiges Konto testen, bevor Sie den Bildschirm mit echten Kundendaten verwenden.

[Erstellen Sie ein Team und laden Sie Mitglieder ein](https://supastack.dev/de/docs/web/organizations.md)

[Überprüfen Sie, dass Datensätze in ihrem Arbeitsbereich privat bleiben](https://supastack.dev/de/docs/web/security.md)


## Workspace aus der Sitzung auflösen

Persönliche Workspaces bilden für jeden Benutzer eine eigene Zuständigkeitsgrenze. Der Server löst den aktuellen Workspace aus dem vertrauenswürdigen Authentifizierungskontext auf. Vom Client gelieferte IDs dürfen diese Prüfung niemals ersetzen.


## Lese- und Schreibzugriffe abgrenzen

Fügen Sie workspaceId in jede Suche und Änderung an benutzereigenen Datensätzen ein. Eine Detailroute benötigt dieselbe Isolation wie eine Listenroute. Aufgaben-IDs, Wiederherstellungs-URLs und Idempotenzschlüssel identifizieren Arbeit, autorisieren aber keinen Zugriff.

Wenden Sie diese Regel ebenso auf Ihre Produkttabellen wie auf gemeinsame Aufgaben-, Nutzungs- und Providerkonfigurationseinträge an.


## Workspace-übergreifende Ablehnung testen

Erstellen Sie zwei unabhängige Workspace-Kontexte. Prüfen Sie, dass der Eigentümer den eigenen Datensatz lesen und ändern kann, der andere Workspace nicht darauf zugreift und anonyme Anfragen abgelehnt werden. Bestätigen Sie, dass abgelehnte Schreibzugriffe den gespeicherten Datensatz unverändert lassen.


## Weiter

[Authentifizierung](https://supastack.dev/de/docs/modules/auth.md)