Rollen & Berechtigungen
Umfassender Leitfaden zu den drei Rollen in CodeCourier-Projekten - Eigentümer, Admin und Mitglied - mit vollständiger Berechtigungsmatrix und Best Practices.
CodeCourier verwendet ein rollenbasiertes Zugriffskontrollsystem (RBAC) mit drei klar abgegrenzten Rollen: Eigentümer, Admin und Mitglied. Jede Rolle erbt alle Berechtigungen der darunterliegenden Rollen, wodurch eine klare Hierarchie entsteht. Diese Seite dokumentiert exakt, was jede Rolle tun kann, und gibt Empfehlungen für die Rollenzuweisung.
Rollenhierarchie
Das Berechtigungsmodell folgt einer strikten Hierarchie:
Eigentümer > Admin > Mitglied
Jede Rolle umfasst alle Berechtigungen der darunterliegenden Rollen. Ein Eigentümer kann alles, was ein Admin kann, und ein Admin kann alles, was ein Mitglied kann.
Rollendefinitionen
Eigentümer
Der Eigentümer ist der Ersteller des Projekts und hat uneingeschränkten Zugriff auf alle Funktionen und Einstellungen. Ein Projekt hat immer mindestens einen Eigentümer, und diese Bedingung wird auf Datenbankebene durchgesetzt - der letzte verbleibende Eigentümer kann nicht entfernt oder degradiert werden.
Eigentümer-exklusive Fähigkeiten:
- Die Rolle eines beliebigen Mitglieds ändern (einschließlich Beförderung anderer zum Eigentümer)
- Andere Eigentümer aus dem Projekt entfernen
- Das Projekt vollständig löschen
- Eigentümerschaft übertragen, indem ein anderes Mitglied befördert und sich selbst degradiert wird
Admin
Admins sind vertrauenswürdige Teammitglieder, die das tägliche Projektmanagement übernehmen können, einschließlich Mitgliederverwaltung und Einstellungskonfiguration. Sie besitzen nahezu alle Berechtigungen eines Eigentümers, mit Ausnahme von Rollenänderungen und destruktiven Aktionen auf Eigentümerebene.
Admin-Fähigkeiten (zusätzlich zu Mitglied):
- Neue Mitglieder zum Projekt einladen
- Mitglieder aus dem Projekt entfernen (außer Eigentümer)
- Ausstehende Einladungen abbrechen
- Projekteinstellungen konfigurieren (API-Schlüssel, System-Prompts, Umgebungsvariablen)
Mitglied
Mitglieder sind reguläre Teamteilnehmer, die alle Projektfunktionen nutzen können, aber weder das Team noch kritische Einstellungen verwalten dürfen. Dies ist die Standardrolle für neue Einladungen.
Mitglieder-Fähigkeiten:
- Alle Projektressourcen einsehen (Sandboxes, Runs, Workflows, Personas, Issue-Sessions, Learnings)
- Eigene Sandboxes und Runs erstellen und verwalten
- Workflows und Personas erstellen und konfigurieren
- Issue-Sessions starten und verwalten
- Eigene Einladungen einsehen und annehmen/ablehnen
- Mitgliederliste einsehen
- Auf Projektanalysen und Nutzungsdaten zugreifen
Berechtigungsmatrix
| Aktion | Mitglied | Admin | Eigentümer |
|---|---|---|---|
| Projektressourcen einsehen | Ja | Ja | Ja |
| Sandboxes und Runs erstellen | Ja | Ja | Ja |
| Workflows erstellen/bearbeiten | Ja | Ja | Ja |
| Personas erstellen/bearbeiten | Ja | Ja | Ja |
| Issue-Sessions starten | Ja | Ja | Ja |
| Mitgliederliste einsehen | Ja | Ja | Ja |
| Analysen und Nutzung einsehen | Ja | Ja | Ja |
| Neue Mitglieder einladen | Nein | Ja | Ja |
| Mitglieder entfernen | Nein | Ja (keine Eigentümer) | Ja |
| Einladungen abbrechen | Nein | Ja | Ja |
| Projekteinstellungen konfigurieren | Nein | Ja | Ja |
| API-Schlüssel konfigurieren | Nein | Ja | Ja |
| Mitgliederrollen ändern | Nein | Nein | Ja |
| Andere Eigentümer entfernen | Nein | Nein | Ja |
| Projekt löschen | Nein | Nein | Ja |
Durchsetzungsmechanismus
Berechtigungen werden serverseitig in jeder Convex-Abfrage und -Mutation durchgesetzt. Das Backend verwendet gemeinsame Authentifizierungs-Hilfsfunktionen, die sowohl Identität als auch Autorisierung prüfen, bevor eine Operation ausgeführt wird:
getProjectForMember(ctx, projectId)- Stellt sicher, dass der aktuelle Nutzer ein aktives (nicht ausstehendes) Mitglied des Projekts ist. Wird von Abfragen verwendet, die grundlegenden Projektzugriff benötigen.requireProjectAdmin(ctx, projectId)- Stellt sicher, dass der aktuelle Nutzer Admin oder Eigentümer des Projekts ist. Wird von Mutationen verwendet, die Mitglieder und Einstellungen verwalten.requireProjectOwner(ctx, projectId)- Stellt sicher, dass der aktuelle Nutzer Eigentümer des Projekts ist. Wird von Mutationen verwendet, die Rollen ändern und destruktive Operationen durchführen.
Diese Prüfungen laufen bei jeder Anfrage, sodass selbst wenn das Frontend versäumt, einen Button auszublenden, das Backend nicht autorisierte Operationen ablehnt.
Clientseitig vs. Serverseitig
Sicherheitsbeschränkungen
Mehrere Sicherheitsregeln verhindern versehentliche Aussperrungsszenarien:
- Schutz des letzten Eigentümers - Wenn nur ein Eigentümer übrig ist, kann dieser Eigentümer nicht entfernt oder degradiert werden. Das System prüft die Anzahl der Eigentümer, bevor eine Degradierung oder Entfernung zugelassen wird.
- Schutz vor Selbstdegradierung - Ein Eigentümer kann sich selbst degradieren, aber nur wenn mindestens ein weiterer Eigentümer existiert, um die Projektverwaltung sicherzustellen.
- Cross-Role-Entfernungsschutz - Ein Admin (Nicht-Eigentümer) kann keinen Eigentümer entfernen. Nur Eigentümer können andere Eigentümer entfernen.
Best Practices
Mit minimalen Berechtigungen beginnen
Weisen Sie beim Einladen neuer Nutzer standardmäßig die Rolle Mitglied zu. Befördern Sie nur dann zum Admin, wenn die Person das Team verwalten oder Projekteinstellungen konfigurieren muss. Behalten Sie die Eigentümer-Rolle Nutzern vor, die vollständige Projektkontrolle benötigen.
Mehrere Eigentümer beibehalten
Weisen Sie für Produktionsprojekte mindestens zwei Eigentümer zu. Dies stellt sicher, dass der Projektzugriff erhalten bleibt, selbst wenn ein Eigentümer nicht verfügbar ist. Es ermöglicht zudem die Eigentumsübertragung ohne externe Intervention.
Mitgliedschaft regelmäßig überprüfen
Überprüfen Sie regelmäßig die Mitgliederliste und entfernen Sie Nutzer, die keinen Zugriff mehr benötigen. Anders als in manchen Systemen verfügt CodeCourier nicht über eine automatische Rollenablauffunktion, daher ist eine manuelle Überprüfung der empfohlene Ansatz.
Benutzerdefinierte Rollen