Skriptfähigkeiten sind experimentell und als Client-Beta verfügbar.
Skriptfähigkeiten ermöglichen es Ihnen, die Aktionen zu steuern, die Skripte im DataModel-Unterbaum ausführen können. Anstelle des standardmäßigen "Alles oder Nichts"-Systems können Sie einem Skript erlauben, nur auf bestimmte Kategorien zuzugreifen, wie z.B. Audio, Physik, Datenstores und mehr.
- Dieses System ermöglicht es Ihnen, einzuschränken, was Modelle aus dem Werkzeugkasten tun können, und es erleichtert die Einbeziehung von nutzergenerierten Inhalten in das Spiel.
- Es kann auch helfen, die Sicherheit von Spielen zu verbessern, die es Spielern ermöglichen, ihren eigenen Code auszuführen, der häufig in einer eingeschränkten oder emulierten Umgebung ausgeführt wird.
- Es kann auch verwendet werden, um Bibliotheken zu teilen, die einschränken, was sie selbst tun können. Zum Beispiel kann eine Bibliothek, die zusätzliche mathematische Methoden bereitstellt, auf den kleinsten Satz von Fähigkeiten beschränkt werden, die sie benötigt, damit andere Entwickler, die diese Bibliothek verwenden, nicht den gesamten Code überprüfen müssen, um sicherzustellen, dass er keinen böswilligen Code enthält.
Skriptfähigkeiten aktivieren
Um diese Funktion zu aktivieren, ändern Sie die Eigenschaft SandboxedInstanceMode von Default auf Experimental im Explorer- und Eigenschaften-Fenster.
Sandbox-Container
Skriptfähigkeiten führen das Konzept eines Sandbox-Containers ein. Models, Folders, Scripts oder Nachkommen einer dieser Klassen haben eine Sandboxed-Eigenschaft, die im Eigenschaften-Fenster verfügbar ist.
Das Aktivieren der Sandboxed-Eigenschaft kennzeichnet die Instanz als Sandbox-Container im DataModel-Baum, was die Aktionen einschränkt, die die Skripte innerhalb dieses Containers basierend auf den Werten in der Capabilities-Eigenschaft ausführen können.
Fähigkeiten
Die Capabilities-Eigenschaft ist eine Menge von Werten, die verschiedene Aspekte der Ausführung steuern. Fähigkeiten fallen in die folgenden breiten Kategorien:
- Ausführungssteuerung - Gibt an, ob ein Skript auf dem Client oder Server ausgeführt werden kann
- Instanzzugriffssteuerung - Gibt an, mit welchen DataModel-Teilen ein Skript interagieren kann
- Skriptfunktionalitätssteuerung - Gibt an, welche Luau-Funktionen Skripte aufrufen können
- Engine-API-Zugriffssteuerung - Gibt an, welche Teile der Roblox Engine API verwendet werden können
Wenn ein Skript versucht, eine Aktion auszuführen, die nicht im Set der Fähigkeiten enthalten ist, gibt Roblox einen Fehler aus. Fehler enthalten typischerweise die versuchte Aktion, das Ziel einer Aktion und die erste fehlende Fähigkeit:
Ausführungssteuerung
Zwei Fähigkeiten steuern die Ausführungssteuerung:
- RunClientScript - LocalScript oder Script mit einem RunContext-Wert von Client darf auf dem Client ausgeführt werden
Wenn das Skript Enabled ist, aber die Fähigkeit, die dem Standort entspricht, an dem es versucht zu starten, nicht verfügbar ist, wird eine Warnmeldung im Output-Fenster angezeigt. Wenn ein Skript nicht in diesem Kontext ausgeführt werden sollte, deaktivieren oder löschen Sie es.
Beachten Sie, dass ModuleScripts nicht diese Ausführungsfähigkeiten haben müssen, um erforderlich zu sein.
Wenn ein Skript aufgrund fehlender Ausführungssteuerungskapazität nicht gestartet werden kann, wird dies als Warnung im Output angezeigt, zum Beispiel:
Instanzzugriffssteuerung
Eine einzige Fähigkeit steuert den Instanzzugriff:
- AccessOutsideWrite - Skript darf Instanzen von außerhalb des Sandbox-Containers abrufen und empfangen
Wenn die Fähigkeit nicht verfügbar ist, kann das Skript nur Instanzen innerhalb seines eigenen Sandbox-Containers abfragen. Wenn das Skript direkt im Sandbox-Container platziert ist, gibt script.Parent.Parent nil zurück.
Außerdem wird jedes Roblox API-Ereignis, das eine Instance übergibt, stattdessen nil für jede Instance außerhalb des Sandbox-Containers übergeben. Wenn beispielsweise das BasePart.Touched-Ereignis durch einen Touch von einer Instanz außerhalb des Sandbox-Containers ausgelöst wird, wird das Ereignis zwar empfangen, aber das Argument ist nil.
Vermeiden Sie es, diese Fähigkeit zu setzen; Sandbox-Garantien sind schwächer, wenn Skripts mit beliebigen Instanzen in einem Spiel interagieren können.
Zugriff auf Dienste
Selbst ohne AccessOutsideWrite können Skripte im Sandbox-Container dennoch auf game, workspace und Dienste zugreifen. Dieser Zugriff wird gewährleistet, damit Skripte weiterhin nützliche Methoden dieser Globals aufrufen können, wie z.B. DataModel.GetService, aber der Zugriff auf deren untergeordnete Instanzen wird weiterhin validiert.
Intern übergebene Instanzen
Wenn eine Instanz über einen Funktionsaufruf übergeben wird, der nicht über Roblox APIs erfolgt, bleibt die Referenz erhalten. Wenn jedoch ein ModuleScript auf diese Weise übergeben wird, kann es ohne AccessOutsideWrite nicht erforderlich sein. Dies liegt daran, dass die Rückgabe des ModuleScript oft veränderbar ist und von einem Skript in einem Sandbox-Container modifiziert werden kann.
Skriptfunktionalitätssteuerung
Diese Menge von Fähigkeiten steuert einige allgemeine Aspekte von Skripten:
- CreateInstances - Skript kann neue Instanzen mit Instance.new, Instance.fromExisting oder Instance:Clone() erstellen
- LoadString - Skript darf loadstring aufrufen
- LoadUnownedAsset - Skript darf require mit einer Asset-ID oder AssetService:LoadAssetAsync() aufrufen
Beachten Sie, dass die standardmäßigen Funktionsbeschränkungen weiterhin gelten. Selbst wenn LoadString aktiviert ist, muss das Spiel es in ServerScriptService aktivieren, und es ist weiterhin nur auf dem Server verfügbar.
Um neue Instanzen zu erstellen, neben CreateInstances, ist eine zusätzliche Engine-API-Fähigkeit erforderlich, die Zugriff auf diese Instanz bietet.
Engine-API-Zugangssteuerung
Diese letzte Gruppe von Fähigkeiten steuert den Skriptzugriff auf verschiedene Engine-APIs:
- Animation - Zugriff auf Instanzen, die mit Animationen zu tun haben
- AssetCreateUpdate - Zugriff auf Engine-APIs, die mit dem Erstellen oder Aktualisieren von Assets zu tun haben
- AssetManagement - Zugriff auf Engine-APIs, die mit Operationen an Assets zu tun haben, die nicht gelesen, erstellt oder aktualisiert werden
- AssetRead - Zugriff auf Engine-APIs, die mit dem Abrufen von Informationen über Assets zu tun haben
- Audio - Zugriff auf Instanzen, die mit Audio-APIs zu tun haben
- AvatarAppearance - Zugriff auf Instanzen, die mit den visuellen Elementen von Avataren zu tun haben
- AvatarBehavior - Zugriff auf Engine-APIs, die mit der Steuerung oder Modifikation des Humanoiden zu tun haben
- Basic - Zugriff auf allgemeine APIs, die wenig Risiko bieten
- CSG - Zugriff auf Instanzen und Funktionen, die mit konstruktiver Festkörpergeometrie (CSG) zu tun haben
- CapabilityControl - Zugriff auf die Modifikation der Sandboxed- und Capabilities-Eigenschaften von Instanzen
- Capture - Zugriff auf Engine-APIs, die mit dem Erstellen von Screenshots oder Videos auf dem Bildschirm des Benutzers zu tun haben
- Chat - Zugriff auf Instanzen, die mit dem In-Game-Chat zu tun haben
- Consequences - Zugriff auf APIs zur Bestrafung von Benutzern (Kicks oder Bans)
- DataStore - Zugriff auf Datenstore- und Speicher-API
- DynamicGeneration - Zugriff auf Engine-APIs, die mit dem dynamischen Modifizieren von Assets zu tun haben
- Environment - Zugriff auf Instanzen, die mit der Kontrolle dessen, wie die Umgebung angezeigt wird, zu tun haben
- Groups - Zugriff auf Engine-APIs, die mit Gruppen/Gemeinschaften zu tun haben
- Input - Zugriff auf Instanzen, die mit Benutzereingaben zu tun haben
- LegacySound - Zugriff auf Engine-APIs, die mit Sounds zu tun haben, die veraltet sein werden
- LoadOwnedAsset - Zugriff auf Engine-APIs zum Laden von Assets, die Ihnen gehören, denen Sie zugewiesen wurden, die Roblox gehören oder ein harmloser Asset-Typ sind
- Logging - Zugriff auf die Logging-API
- Material - Zugriff auf Engine-APIs, die mit Materialien zu tun haben
- Monetization - Zugriff auf Engine-APIs, die mit der Monetarisierung eines Spiels zu tun haben, wobei die meisten PromptPurchases ausgeschlossen sind
- Network - Zugriff auf HTTP-Netzwerk-APIs
- Physics - Zugriff auf Instanzen, die mit Physik zu tun haben
- PlatformAvatarEditing - Zugriff auf Engine-APIs, die mit dem Erstellen oder Aktualisieren von Avataren zu tun haben, oder APIs, um dabei zu helfen
- Players - Zugriff auf Engine-APIs, die mit der Player-Klasse zu tun haben oder die Players.LocalPlayer zurückgeben/interagieren
- PromptExternalPurchase - Ermöglicht den Zugriff auf Engine-APIs, die mit dem Auffordern des Kaufs willkürlicher Assets zu tun haben
- RemoteEvent - Zugriff auf Instanzen für interne Netzwerkoperationen
- SensitiveInput - Zugriff auf Engine-APIs, die mit dem Erfassen sensibler Eingaben vom Benutzer zu tun haben, d.h. hochprivaten Hardware-Sensoren.
- ServerCommunication - Zugriff auf Engine-APIs, die mit der serverübergreifenden Kommunikation zu tun haben, wie z.B. MessagingService
- Social - Zugriff auf Engine-APIs, die mit sozialen Funktionen zu tun haben, wie z.B. Freunden und Einladungen
- Teleport - Zugriff auf Engine-APIs, die mit Teleportieren zu tun haben
- UI - Zugriff auf Instanzen, die mit Benutzeroberflächen zu tun haben
Die Fähigkeiten jeder Klasse, Eigenschaft, Methode und Ereignis werden im Engine API-Verweis angezeigt. Zum Beispiel erfordert Player:GetFriendsOnlineAsync() die Player- und Social-Fähigkeiten.
Mehrere HttpService-Methoden sind ohne irgendwelche Fähigkeiten verfügbar, abgesehen von der Fähigkeit, die Skripte auszuführen:
Wenn eine Instanzeigenschaft oder Methode ohne die erforderliche Fähigkeit zugegriffen wird, wird ein Fehler berichtet, der die fehlende Fähigkeit beschreibt.
Schließlich decken Fähigkeiten nicht jede Instanz in der Roblox Engine heutzutage ab. Instanzen, die in diesem Abschnitt oder im folgenden nicht aufgeführt sind, sind nicht für eine Interaktion aus einem Sandbox-Container verfügbar und werfen einen Fehler aus, der besagt, dass eine nichtzugeordnete Fähigkeit für das aktuelle Skript nicht verfügbar ist.
Eine zusätzliche Einschränkung ist, dass die Funktionen getfenv() und setfenv() für Skripte in einem Sandbox-Container nicht verfügbar sind. Der Aufruf dieser Funktionen von einem Sandbox-Skript berichtet:
Nur der Zugriff von Skripten auf Instanzen ist eingeschränkt. Die Instanzen selbst können weiterhin existieren und innerhalb eines Sandbox-Containers autonom operieren. Lichter strahlen weiterhin, Benutzeroberflächen sind weiterhin sichtbar, und Audio-Setups, die bereits verkabelt sind, spielen Sounds.
Interaktionen zwischen Containern
Verschachtelte Container
Wenn ein Sandbox-Container in einem anderen verschachtelt ist, sind die Instanzen des inneren Containers für den äußeren zugänglich.
Die Fähigkeiten des inneren Containers werden durch die Fähigkeiten des äußeren Containers eingeschränkt. Wenn der äußere Container beispielsweise die Fähigkeiten Basic, Audio und CSG hat, der innere Container jedoch Basic und Network hat, sind nur die Fähigkeiten Basic zur Laufzeit des inneren Containers verfügbar.
Wenn keine Fähigkeiten zwischen den inneren und äußeren Containern gemeinsam sind, ist die resultierende Fähigkeitenset leer.
Bindbare Funktionen und Ereignisse
BindableEvent und BindableFunction bieten die beste Möglichkeit, mit dem Container zu kommunizieren oder ihm zu erlauben, Rückrufe mit Fähigkeiten auszuführen, die ihm selbst nicht direkt erlaubt sind.
Wenn ein Ereignis ausgelöst oder eine Funktion aufgerufen wird, werden die Verbindungen im Kontext der Funktion ausgeführt, die sie registriert hat. Das bedeutet, dass, wenn der Rückruf des Ereignisses oder der Funktion vom Sandbox-Container registriert ist, er mit den Fähigkeiten dieses Containers aufgerufen wird. Wenn der Rückruf von dem Code außerhalb registriert wird, führen die Skripte des Sandbox-Containers Ihre Funktionen mit den Fähigkeiten aus, die Ihren Funktionen zur Verfügung stehen.
Es ist wichtig zu beachten, dass selbst mit der AccessOutsideWrite-Fähigkeit Skripte in Sandbox-Containern keine Ereignisse oder Funktionen außerhalb ihrer Container aufrufen können, wenn sie ein größeres Fähigkeitsset haben als der Container selbst.
Wenn ein Sandbox-Skript versucht, ein Ereignis oder eine Funktion (BindableEvent, BindableFunction oder RemoteEvent) auszulösen, dessen übergeordnete Fähigkeiten seine eigenen überschreiten, gibt die Fehlermeldung die Eigenschaft an, die untersucht werden soll.
Wenn das Ziel sich nicht in einem Sandbox-Container befindet:
Um dies zu beheben, setzen Sie Sandboxed auf true für das Ziel. Alternativ können Sie die Quelle des aufrufenden Threads so ändern, dass Sandboxed auf false gesetzt ist, was jedoch nicht empfohlen wird, da es die Sicherheitsvorteile der Sandboxung beseitigt.
Wenn das Ziel sandboxed ist, aber Fähigkeiten hat, die dem Aufrufer fehlen:
Um dies zu beheben, schränken Sie die Capabilities des Ziels auf eine Teilmenge des Aufrufers ein, oder erweitern Sie die Capabilities des Aufrufers, um mit den Fähigkeiten des Ziels übereinzustimmen.
Modul anfordern
Innere ModuleScripts können wie gewohnt vom Sandbox-Container angefordert werden. Wenn jedoch die Zielinstanz außerhalb des Containers liegt, kann das ModuleScript nur angefordert werden, wenn das verfügbare Fähigkeitsset, das ihm zur Verfügung steht, kleiner oder gleich den Fähigkeiten ist, die dem Container zur Verfügung stehen.
Diese Einschränkung gilt nicht für RunClientScript- und RunServerScript-Fähigkeiten. Wenn das ModuleScript in einem Container mit nur RunClientScript platziert ist, aber von einem Skript angefordert wird, das die RunServerScript-Fähigkeit hat, darf es erfolgreich ausgeführt werden und diese Funktionen auf dem Server ausführen.
Wenn require() aufgrund eines Fähigkeitsmismatchs fehlschlägt, gibt die Fehlermeldung das Zielmodul und die Eigenschaft an, die in gleicher Weise wie bindbare Funktionen und Ereignisse in Abschnitt vorher untersucht werden soll.
Direkt aufgerufene Funktionen
Wenn ein ModuleScript in einem Sandbox-Container von außerhalb des Containers angefordert wird, sind einige der Schutzmaßnahmen nicht verfügbar. Insbesondere ist die Ziel-Funktion in der Lage, auf alle Instanzen zuzugreifen, die dem Aufrufer zur Verfügung stehen. Wenn der Aufrufer sich nicht in einem Sandbox-Container befindet, erfolgt der Aufruf so, als ob AccessOutsideWrite für ihn verfügbar ist.
Andere Einschränkungen der Fähigkeiten gelten weiterhin. Wenn Sie eine DataStore-Zugriffsfähigkeit haben, das Ziel-Modul jedoch nicht, kann es keine DataStore-Methoden aufrufen. Wenn Sie jedoch Ihre eigene Funktion übergeben, die mit DataStore arbeitet, kann das Ziel sie während dieses Aufrufs ausführen. Wenn das Ziel einen Thread mit Methoden wie denen von task plant, verlieren diese Threads die Fähigkeit, diese Funktion aufzurufen.
Instanzen können an das Zielmodul übergeben oder den Modulfeldern zugewiesen werden.
Bei Bedarf wird empfohlen, Tabellenmitglieder mit rawset zuzuweisen, um zu vermeiden, dass __index/__newindex-Metamethoden ausgeführt werden, die möglicherweise auf der Tabelle festgelegt sind.
Die allgemeine Empfehlung ist, mit BindableEvent und BindableFunction zu kommunizieren, wann immer dies möglich ist.
Bewegung von Instanzen
Die meisten Instanzen haben keine Einschränkungen hinsichtlich der Bewegung zwischen Containern. Skriptinstanzen hingegen können nur in einen Container verschoben werden, der dasselbe Fähigkeits-Set oder eine Teilmenge dieser Fähigkeiten hat.
Das bedeutet, dass ein Sandbox-Container mit AccessOutsideWrite ein Skript nicht einfach in sich selbst umgestalten und dadurch mehr Fähigkeiten erhalten kann.