Berechtigungen

Einführung

Die Registerkarte Permissions legt für ein bestimmtes Repository fest, wer in welchen Ordnern lesen oder schreiben darf. Eine Berechtigung richtet sich an eine Gruppe oder einen Benutzer, gilt für ein Pfadmuster und trägt eine Stufe (write / read / none). Die Rolle sagt, was ein Konto tun darf; die Berechtigung sagt, für welche Dateien.

Zugriff und Rollen

Die Registerkarte steht dem Super-Admin (alle Repositories) und dem project_admin (die von ihm verwalteten Repositories) zur Verfügung. Regeln sind immer an das ausgewählte Repository gebunden.

Die drei Panels der Registerkarte

Die Registerkarte Permissions befindet sich in der Zeile PROJECT des Administrationsbereichs: Alles, was Sie dort tun, gilt nur für das im Auswahlfeld am Kopf der Zeile angezeigte Repository. Die Zeile SERVER direkt darüber betrifft dagegen den gesamten Server, und dort leben die Konten und die Gruppen.

Die Registerkarte stapelt drei verschiedene Panels, von oben nach unten. Sie beantworten drei verschiedene Fragen, und die ersten beiden mit dem Ordnerbaum zu verwechseln ist der häufigste Anlass für Rückfragen auf dieser Seite.

Der Rest dieser Seite beschreibt zuerst den Berechtigungsbaum, das Hauptpanel, dann die beiden anderen.

Die drei Stufen

Zugriff gewähren

1. Die Registerkarte Permissions im richtigen Projekt öffnen

Zeile PROJECT, Repository-Auswahlfeld am Kopf der Zeile: Prüfen Sie zuallererst das angezeigte Projekt, die Regeln werden nur ihm zugeordnet.

2. Das Subjekt wählen

Nehmen Sie im Auswahlfeld eine Gruppe oder einen Benutzer: Die Liste ist in zwei Unterlisten geteilt, Groups und Users. Eine Regel betrifft das eine oder das andere, niemals beide. Solange kein Subjekt gewählt ist, bleibt die Schaltfläche Apply inaktiv.

3. Die Ordner markieren

Markieren Sie im Ordnerbaum die betroffenen Ordner. Die Kästchen haben drei Zustände (alles, teilweise, nichts), und das Feld Filter folders... kürzt den Baum, wenn das Projekt groß ist.

4. Die Stufe wählen und anwenden

Sobald ein Ordner markiert ist, erscheint eine Leiste: Sie nennt die Anzahl der ausgewählten Ordner und bietet die drei Stufen (write, read, none). Wählen Sie eine und klicken Sie dann auf Apply. Die Regeln des Subjekts erscheinen daraufhin darunter in der Tabelle Active rules (Path Pattern, Permission, Priority), wo Sie sie einzeln löschen können.

Nach Benutzername gewähren

Mit der Schaltfläche "+ By username" können Sie jemandem Zugriff gewähren, der nicht in der sichtbaren Liste erscheint, indem Sie seinen exakten Namen eingeben. So gewähren Sie einem Konto außerhalb Ihres üblichen Bereichs Zugriff, zum Beispiel einem playtester, der noch keine Berechtigung besitzt.

Der Name muss exakt übereinstimmen (kein Präfix). Das Feld gibt nur die Kennung und den Namen zurück, niemals die Rolle, damit es nicht zum Aufspüren bestehender Konten dient.

Muster und Priorität

Eine Regel zielt nicht auf eine bestimmte Datei, sondern auf ein Pfadmuster, einen sogenannten Glob: eine Kurzschreibweise, in der * für eine beliebige Folge von Zeichen in einem Namen steht und ** für eine beliebige Folge von Ordnern in beliebiger Tiefe. So bezeichnet Content/Maps/** alles unterhalb von Content/Maps, Unterordner eingeschlossen. Sie müssen sie nicht von Hand schreiben: Das Markieren eines Ordners im Baum erzeugt den entsprechenden Glob.

Ein markierter Ordner Foo/Bar wird zum Muster Foo/Bar/** (der Ordner und alles, was er enthält, in beliebiger Tiefe). Die Wurzel des Repositorys wird zu /**.

Jede Regel erhält eine automatische Priorität gleich der Tiefe des Ordners (Anzahl der Segmente, Wurzel = 0). Eine spezifischere (tiefere) Regel setzt sich daher gegen eine allgemeinere durch. Beispiel: write auf Content/** und none auf Content/Secret/** ergibt Schreibzugriff überall in Content/ außer in Secret/.

Standardauflösung

Wenn keine explizite Regel einen Pfad abdeckt, folgt der effektive Zugriff diesem Modell:

• Standardmäßig ist der Zugriff read (Lesen), wenn keine Regel zutrifft.
• admin und lead haben überall write (Rollen-Bypass).
• Ein project_admin hat write auf den von ihm verwalteten Repositories und sonst nichts Besonderes.
• Andernfalls gilt die spezifischste Regel; fehlt sie, das standardmäßige Lesen.

Mit anderen Worten: Um jemandem, der bereits Zugriff auf das Repository hat, das Lesen eines Ordners zu verbieten, genügt es nicht, nichts zu gewähren (der Standard ist read), es braucht eine explizite none-Regel.

Praktische Folge, die unnötige Arbeit spart: ein brandneues Projekt ohne jede Regel ist bereits für alle geschlossen, außer für die Rollen admin und lead und seine eigenen project_admins. Es ist also nicht nötig, überall none-Regeln zu setzen, um ein Projekt zu "schließen"; es genügt, nur das zu gewähren, was Sie öffnen wollen. none-Regeln dienen dazu, innerhalb eines bereits gewährten Zugriffs abzugrenzen, zum Beispiel um Content/Secret/ vor einem Team zu verbergen, das Content/ hat.

Einen Projektadministrator benennen

Das Panel Project Admins oben in der Registerkarte legt fest, wer das ausgewählte Repository verwaltet. Es ist dem Super-Admin vorbehalten: Autorität zu verleihen ist eine Stufe über ihrer Ausübung.

Das Vorgehen erfolgt in zwei Schritten, in dieser Reihenfolge:

1. Die Rolle vergeben, in der Registerkarte Users

Zeile SERVER, Registerkarte Users: Geben Sie der Person die Rolle project_admin. Solange diese Rolle nicht gesetzt ist, erscheint sie nicht in der Liste dieses Panels, was Ihnen dort auch mitgeteilt wird: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Die Person an das Repository binden

Kommen Sie hierher zurück, prüfen Sie das im Auswahlfeld der PROJECT-Zeile angezeigte Repository, und klicken Sie dann im Panel Project Admins auf Add, wählen Sie die Person und klicken Sie auf Grant. Sie erscheint sofort in der Liste des Panels.

Eine Bindung entfernen

Das rote Kreuz am Zeilenende (Revoke) entfernt das Repository aus ihrem Bereich. Die Rolle ohne die Bindung gibt nichts: ein project_admin, der kein Repository mehr verwaltet, verliert den Zugriff auf Permissions, Rules, Webhooks, Files und die Benutzerverwaltung. Das Entfernen des letzten Repositorys entfernt also tatsächlich die gesamte Autorität.

Build-Zugriff

Das Panel Build Access entscheidet, wer die veröffentlichten Builds dieses Projekts auf der Games-Seite des Clients sehen und herunterladen kann. Es steht dem Super-Admin und dem project_admin auf seinen Repositories offen.

1. Das Hinzufügen-Formular öffnen

Klicken Sie im Panel Build Access auf Add. Eine Eingabezeile erscheint, die mit der Wahl beginnt, wie das Ziel bezeichnet wird.

2. Das Ziel bezeichnen

• User: ein Konto aus der Liste, also jemand, der bereits am Projekt arbeitet.
• Group: eine ganze Gruppe, praktisch für einen Studierendenjahrgang oder ein wiederkehrendes Testteam.
• By username: ein Feld Exact username, in das Sie den exakten Namen des Kontos eingeben. Das ist der normale Weg für einen playtester, da er in keiner Liste auftaucht. Der Name muss exakt übereinstimmen, ohne Präfix.

3. Gewähren oder entziehen

Klicken Sie auf Grant, um zu gewähren. In einer bestehenden Zeile entfernt Revoke den Zugriff, mit einer Bestätigung.

Die vom Server angewandte Regel, in dieser Reihenfolge:

Mit anderen Worten: Wer bereits am Projekt arbeitet, braucht hier nichts weiter. Dieses Panel dient Personen außerhalb des Projekts, und ein viewer bleibt in jedem Fall ausgeschlossen.

Eine Berechtigung testen

Das Panel Test Permission ganz unten in der Registerkarte beantwortet "welchen effektiven Zugriff hat dieser Benutzer auf diesen Pfad?". Es ist der kürzeste Weg, um zu erfahren, welche Ihrer Regeln wirklich entscheidet.

1. Den Benutzer und den Pfad wählen

Nehmen Sie ein Konto in User, geben Sie dann einen Pfad in Path ein, zum Beispiel /Content/Maps/Level01.umap. Die Schaltfläche bleibt inaktiv, solange nicht beide ausgefüllt sind.

2. Den Test starten und das Ergebnis lesen

Klicken Sie auf Test. Das Ergebnis zeigt die effektive Stufe sowie die Quelle und das Muster, die entschieden haben, sodass Sie verstehen, warum ein Zugriff gewährt oder verweigert wird.

Für einen Benutzer, den Sie nicht sehen dürfen, gibt der Test dasselbe "nicht gefunden" zurück wie bei einem nicht existierenden Konto, um die Existenz von Konten nicht preiszugeben.

Häufige Fallstricke

"Ich habe nichts gewährt, trotzdem kann er lesen"

Das ist der read-Standard, und er greift nur innerhalb eines Repositorys, auf das die Person bereits Zugriff hat. Um jemandem, der am Projekt arbeitet, einen Ordner zu schließen, setzen Sie eine explizite none-Regel darauf.

"Das Repository erscheint nicht in seiner Liste"

Das ist normal, solange er auf diesem Repository keine Regel außer none hält. Der read-Standard gibt keinen Zugriff auf das Repository selbst. Gewähren Sie ihm mindestens eine read- oder write-Regel, direkt oder über eine Gruppe, und das Repository erscheint. Wenn es sich um einen playtester handelt, der nur die Builds abholen soll, ist hier nicht der Ort zu handeln: siehe Build-Zugriff.

Zwei Regeln widersprechen sich

Die spezifischste (größte Tiefe) gewinnt. Verwenden Sie den Test, um zu sehen, welche entscheidet.

Ein Lead bleibt trotz einer none-Regel im Schreibzugriff

Die Rollen admin und lead umgehen die Pfadregeln (überall write). Eine none-Regel schränkt sie nicht ein. Dasselbe gilt für einen project_admin auf seinen eigenen Repositories.

Zugriff über Gruppe vs. direkter Zugriff

Ein Zugriff kann vom Konto selbst oder von einer Gruppe stammen, der es angehört. Wenn das Entfernen einer Regel nichts ändert, suchen Sie die andere Quelle (der Test zeigt, welche gilt).