Grundlegende Übersicht / Anleitung zu Assen und Prinzipien – Server-Tutorials

Asse und Principals sind das in fxserver integrierte Standardsystem für Berechtigungen. Es ist sehr einfach zu bedienen, solange Sie die Grundlagen kennen und gerade erst anfangen, einige Dinge auszuprobieren.

Es ist auch sehr einfach, dies innerhalb von Ressourcen zu verwenden. Benutz einfach ExecuteCommand() Asse oder Principals hinzufügen / entfernen und verwenden IsPlayerAceAllowed() um zu überprüfen, ob ein Spieler Zugriff auf ein Ass hat (entweder direkt oder über geerbte Berechtigungen).

---

Auftraggeber

Lassen Sie uns zunächst einen Blick darauf werfen, was a Schulleiter ist, und wie Sie es auf einfachste Weise verwenden können.
Auftraggeber sind Bezeichner, die Berechtigungen (Asse) enthalten. Diese Kennungen können entweder Spielerkennungen (IP, Steam oder Lizenz) sein. oder Sie können Bezeichner sein (wie: group.admin, group.moderator, vip oder snail).

Befehlssyntax

Der Befehl zum Hinzufügen von Bezeichnern hat die folgende Syntax:

# Adds the child principal to the parent principal.
add_principal <child_identifier> <parent_identifier>

# Removes the child principal from the parent principal.
remove_principal <child_identifier> <parent_identifier>

Beispiel

Nehmen wir an, wir haben 2 Spieler. “Spieler A” und “Spieler B”. Wir gehen davon aus, dass ihre (gefälschten) Kennungen sind: player:a und player:b. Wir haben auch 2 Gruppen, die identifiziert werden durch: snail und group.admin.
Um der Gruppe “Schnecke” “Spieler A” hinzuzufügen, können Sie den folgenden Befehl in der Serverkonsole verwenden:

add_principal identifier.player:a snail

Jetzt alle Asse die zur Gruppe “Schnecke” hinzugefügt werden, werden automatisch für festgelegt identifier.player:a (also “Spieler A”).

Erbe

Auftraggeber kann auch erben von andere Auftraggeber. Wenn die Gruppe “group.admin” beispielsweise auch alle Berechtigungen von der Gruppe “snail” erhalten soll, gehen Sie folgendermaßen vor:

add_principal group.admin snail

HINWEIS Es gibt einen wichtigen Haken bei der Verwendung der Vererbung, der im Abschnitt erläutert wird Asse Sektion.

eingebaut

Das builtin.everyone Prinzipal ist eine „Gruppe“, in der sich jeder einzelne Spieler befindet. Wenn Sie also zulassen, dass ein bestimmtes Ass eingebaut wird, hat jeder dieses Ass wie erlaubt.
Selbst wenn Sie jemanden zu einer bestimmten Gruppe / einem bestimmten Prinzipal hinzufügen, erben diese immer alle Berechtigungen von builtin.everyone.

Zu diesem Zeitpunkt sollte der Vererbungsbaum ungefähr so ​​aussehen:

builtin.everyone # (global parent of everything)
|
| .... snail # (parent & child)
|       |
| ....  +---- group.admin # (child, has all "snail" permissions)
|       |
| ....  +--- identifier.player:a # (child, has all "snail" permissions)

---

Asse

Asse können als “Berechtigungsknoten” angesehen werden dürfen oder verweigert.
Standardmäßig sind alle Asse auf eingestellt unset aka deny. Das heißt, wenn Sie nach einem Ass suchen, das nicht eingerichtet wurde, wird es zurückkehren false (verweigern).

Der Standard unset Der Wert kann überschrieben werden, indem er (manuell) auf einen der beiden Werte gesetzt wird deny oder allow. Etwas einstellen auf deny wird es tatsächlich auf setzen DENY-ALWAYS. Das heißt, es kann NICHT von so etwas wie übergeordneten Principals überschrieben werden. Einstellen auf allow gewährt das Ass und kann auch NICHT von den übergeordneten Schulleitern überschrieben werden. Im Grunde ist es nur ein Faust kommt zuerst dienen Prinzip, die erste zu setzende Erlaubnis, kann nicht überschrieben werden, indem sie in den entgegengesetzten Zustand versetzt wird nach Einstellen des ersten Zustands.

Ace-Befehlssyntax

# Adds the ace to the principal, and either "allows" or "denies" it.
add_ace <principal_identifier> <ace_string> <allow|deny>

# Removes the ace from the principal, note it only removes the "allow" or "deny" ace, depending on whichever one you select.
remove_ace <principal_identifier> <ace_string> <allow|deny>

Schauen Sie sich zur Veranschaulichung das folgende Beispiel an:

Beispiel

Lass uns nehmen Spieler A. und Spieler B., Schnecke und Gruppenadministrator Prinzipien aus dem vorherigen Beispiel.
Im vorherigen Beispiel haben wir hinzugefügt PLayer A. zum Schnecke Gruppe, und wir setzen auch die Gruppenadministrator Gruppe, um alles von der zu erben Schnecke Schulleiter (Gruppe)
Sagen wir das mal Spieler B. wurde dem hinzugefügt Gruppenadministrator Schulleiter. (add_principal identifier.player:b group.admin)

Zu diesem Zeitpunkt sieht der Vererbungsbaum folgendermaßen aus:

builtin.everyone # (global parent of everything)
|
| .... snail # (parent & child)
|       |
| ....  +---- group.admin # (parent & child, has all "snail" permissions)
|       |       |
| ....  |  ...  +--- identifier.player:b # (child, has all "group.admin" AND all "snail" permissions)
|       |
| ....  +--- identifier.player:a # (child, has all "snail" permissions)

Wenn wir geben wollen Spieler B. das i.am.cool ace, wir haben 4 Möglichkeiten, dies in diesem aktuellen Setup zu tun.

1. Fügen Sie das Ass hinzu builtin.everyone
2. Fügen Sie das Ass hinzu snail
3. Fügen Sie das Ass hinzu group.admin
4. Fügen Sie das Ass direkt hinzu identifier.player:b

Wir möchten es jedoch wahrscheinlich nur zur 3. oder 4. Option hinzufügen. Weil das Hinzufügen zu 1 es jedem gewährt, und wir wollen das nicht, und das Hinzufügen zu Option 2 ermöglicht es jedem in der Schneckengruppe, es zu verwenden, was auch in diesem Fall nicht das ist, was wir wollen.

Also das hinzufügen i.am.cool Ass zum group.admin Prinzipal, wir würden so etwas tun:

add_ace group.admin "i.am.cool" allow

Das group.admin Schulleiter und alle untergeordneten Schulleiter (in diesem Fall identifier.player:b), haben jetzt Zugriff auf die i.am.cool As.

Platzhalter

Natürlich haben Asse Platzhalter!
Nehmen wir also an, wir wollen geben Spieler A. Erlaubnis zu jeder i.am.*** Ass, weil Spieler A ist .cool, .awesome und .snailsome auch. Dann können wir einfach das hinzufügen i.am Ass zu identifier.player:a, jetzt hat Spieler a alle i.am.*** As.

add_ace identifier.player:a "i.am" allow
# Player a is now: cool, awesome and snailsome!

Spieler B ist jedoch immer noch nur cool. Lasst uns machen Spieler B. snailsome auch, weil sie Teil der sind snail Gruppe schließlich. Aber wir NICHT will ihnen das geben i.am.awesome As. In diesem Fall wir könnten fügen Sie einfach die i.am.snailsome Ass zu entweder der group.admin oder identifier.player:b Auftraggeber, aber wir werden es etwas anders machen, nur weil WIR KÖNNEN. Also, wie machen wir das, fragen Sie sich vielleicht? Na einfach so:

add_ace group.admin "i.am.awesome" deny
add_ace group.admin "i.am" allow
# Player b is now: cool & snailsome but NOT awesome!

Beachten Sie, wie wir die einstellen deny für die i.am.awesome zuerst und dann wir setzen die i.am Platzhalter zu erlauben. Denken Sie daran, was wir über die gesagt haben Wer zuerst kommt, mahlt zuerst?
Jetzt hat group.admin (und damit Spieler B) Zugriff auf alle Status i.am.cool und i.am.snailsome AUSSER für einen, der der ist i.am.awesome Ass, weil wir das so einstellen, dass es leugnet ZUERST.

---

Um alles oben zusammenzufassen, finden Sie hier eine kurze Übersicht aller Befehle + 2 Befehle, die oben nicht aufgeführt sind.