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
undplayer:b
. Wir haben auch 2 Gruppen, die identifiziert werden durch:snail
undgroup.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.
- Fügen Sie das Ass hinzu
builtin.everyone
- Fügen Sie das Ass hinzu
snail
- Fügen Sie das Ass hinzu
group.admin
- 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.
Befehlssyntax | Beschreibung |
---|---|
add_ace <principal_identifier> <ace_name> <allow/deny> |
Legt das Ass für die angegebene Hauptkennung so fest, dass es entweder zulässt oder verweigert. |
removes_ace <principal_identifier> <ace_name> <allow/deny> |
Entfernt entweder das Zulassungs- oder das Verweigerungs-Ass für diesen Principal. |
add_principal <child_principal> <parent_principal> |
Fügt den untergeordneten Principal dem übergeordneten Principal hinzu und gibt dem Kind alle Asse des übergeordneten Principals. |
remove_principal <child_principal> <parent_principal> |
Entfernt den untergeordneten Principal aus dem angegebenen übergeordneten Principal (widerruft alle zuvor geerbten Berechtigungen). |
Bonusbefehle | |
list_aces |
Zeigt eine Liste aller Asse für jede Hauptkennung an und zeigt den gewährten Status an (zulassen, verweigern (/ nicht gesetzt) oder immer verweigern). |
list_principals |
Zeigt eine Liste aller Schulleiter an (Kind> Elternteil) |