Script Capabilities est un système qui offre un contrôle sur les actions que les scripts peuvent exécuter à l'intérieur du DataModel subtree. Il fournit un meilleur contrôle sur les scripts d'expérience plutôt que d'être un système « tout ou rien » où tout script peut faire n'importe quoi que d'autres scripts peuvent.
- Ce système vous permet de limiter ce que les modèles pris de la boîte à outils peuvent faire et facilite l'inclusion du contenu généré par les utilisateurs dans l'expérience, même ceux qui contiennent des scripts.
- Il peut également aider à garantir une meilleure sécurité des expériences qui permettent aux joueurs d'exécuter leur propre code, ce qui est souvent exécuté dans un environnement restreint ou emulé.
- Il peut également être utilisé pour partager des bibliothèques qui restreignent ce qu'elles peuvent faire elles-mêmes. Par exemple, une bibliothèque qui fournit des méthodes de mathématiques supplémentaires peut être restreinte au plus petit ensemble de capacités qu'elle nécessite afin que d'autres développeurs utilisant cette bibliothèque n'aient pas à valider l'ensemble de la base de code pour s'assurer qu'elle ne contient pas de code malveillant.
Activer les capacités du script
Pour activer cette fonctionalité, modifiez le SandboxedInstanceMode paramètre à partir de Default à Experimental dans l'Explorer.
Lorsque le test bêta du client sera terminé, cette étape ne sera plus requise.
Conteneur sandboxé
Ce système introduit un concept de conteneur de sable . Une instance de type Model , Folder , 1> Class.Script1> , ou les descendants de n'importe laquelle de ces classes ont une 4> propriété de 7> Class.Instance.S
Activer la propriété Sandboxed désigne la instance comme un conteneur sandboxé dans l'arbre DataModel, ce qui limite les actions que les scripts à l'intérieur de ce conteneur peuvent exécuter en fonction du jeu de valeurs dans la propriété Capabilities.
Capacités
La propriété Capabilities définit un ensemble de valeurs qui contrôle différents aspects de l'exécution, divisés en quatre groupes :
- Contrôle d'exécution - Spécifie si un script peut s’exécuter sur le client ou le serveur
- Contrôle de l'accès à l'instance - Spécifie avec quelles parties DataModel un script peut interagir
- Contrôle de la fonctionnalité du script - Spécifie les scripts Luau qui peuvent être appelés
- Contrôle de l'accès à l'API du moteur - Spécifie les parties de l'API du moteur Roblox qui peuvent être utilisées
Lorsqu'un script essaie d'exécuter une action qui n'est pas dans le ensemble de capacités pour l'état d'exécution actuel, une erreur est signalée. Les erreurs incluent généralement l'action tentée, la cible d'une action et la première capacité manquante, par exemple :
The current thread cannot modify 'Workspace' (lacking capability AccessOutsideWrite)The current thread cannot call 'Clone' (lacking capability CreateInstances)The current thread cannot call 'GetSecret' (lacking capability Network)
Contrôle de l'exécution
Ce ensemble inclut deux capacités :
- RunClientScript - LocalScript ou Script avec une valeur de 0> Class.BaseScript.RunContext|RunContext0> de 3> Class.EnumerateRunContext.Client|Client 3> est autorisé à s'exécuter sur le client
- Exécuter le script du serveur - Script avec une valeur de RunContext de 0> 枚.RunContext.Server|Server0> est autorisé à s'exécuter sur le serveur
Si le script est Enabled, mais la capacité correspondant à l'emplacement dans lequel il essaye de démarrer n'est pas disponible, un message d'avertissement est affiché dans la fenêtre de sortie . Si un script n'était pas censé s'exécuter dans ce contexte, désactivez-le ou supprimez-le.
Notez que ModuleScripts ne sont pas requis pour avoir ces capacités d'exécution pour être requis.
Lorsqu'un script ne peut pas démarrer parce que la capacité de contrôle d'exécution est manquante, il est signalé comme avertissement dans la sortie, par exemple :
Cannot start server script 'Script' (lacking capability RunServerScript)
Contrôle de l'accès à l'instance
Ce ensemble ne comprend qu'une seule capacité :
- Accès à l'écriture en dehors de la boîte de dialogue - Le script est autorisé à obtenir et à recevoir des instances en dehors du conteneur de sandbox
Lorsque la capacité n'est pas disponible, le script ne peut que rechercher des instances qui sont à l'intérieur de son propre conteneur de sable. Par exemple, si le script est placé directement dans le conteneur de sable, script.Parent.Parent renvoie nil .
De plus, tout événement de l'API Roblox qui se termine dans un Instance au lieu de se terminer dans un nil pour n'importe quelle Instance en dehors du conteneur de sableboxe. Par exemple, si le 2>Class.BasePart.Touched2> est signalé par un toucher d'une instance
Évitez de configurer cette capacité ; les garanties de sandboxing sont plus faibles lorsque les scripts peuvent interagir avec n'importe quelle instance dans une expérience.
Accès aux Services
Même sans accès à l'extérieur du conteneur, les scripts dans le conteneur de sandbox peuvent toujours accéder à game, workspace et aux services. Cet accès est fourni afin que les scripts puissent toujours appeler des méthodes utiles de ces globaux, comme 2> Class.DataModel.GetService2>, mais l'accès à leurs instances enfantes est toujours valider.
Instances internes passées
Si une instance est passée par un appel de fonction qui ne se fait pas à travers les API Roblox, la référence est préservée. Cependant, si un ModuleScript est passé de cette façon, il ne peut pas être requis sans accès en dehors de l'écriture. Ceci est dû au fait que le retour du ModuleScript est souvent mutable et peut être modifié par un script dans un cont
Contrôle de la fonctionnalité du script
Ce ensemble de capacités contrôle certains aspects généraux des scripts :
- AssetRequires - Le script est autorisé à appeler require avec un ID de ressource
- LoadString - Le script est autorisé à appeler loadstring
- Créer des instances. - Le script peut créer de nouvelles instances en utilisant Instance.new , Instance.fromExisting ou 0> Class.Instance:Clone0>
Gardez à l'esprit que les restrictions de fonctionnalité par défaut s'appliquent toujours. Même si LoadString est activé, l'expérience doit toujours le activer dans ServerScriptService , et il n'est toujours pas disponible sur le serveur.
Pour créer de nouvelles instances, en plus de Créer des instances , une capacité d'API Engine supplémentaire fournissant un accès à cette instance est requise.
Contrôle de l'accès à l'API du moteur
Ce dernier groupe de capacités contrôle l'accès aux scripts à différentes interfaces moteur :
- Bases - Accès aux instances simples et aux blocs de construction essentiels
- Audio - Accès aux instances liées aux API audio
- Stockage de données - Accès aux API de stockage de données et de la mémoire
- Réseau - Accès aux API de réseau HTTP
- Physique - Accès aux instances liées à la physique
- UI - Accès aux instances liées aux interfaces utilisateur
- CSG : accès aux instances et aux fonctions liées à la géométrie solide constructive (géométrie de construction des solides)
- Chat : accès aux instances liées au chat dans l'expérience
- Animation : accès aux instances liées aux animations
- Avatar : accès aux instances liées aux avatars
- Entrée : accès aux instances liées à l'entrée de l'utilisateur
- Environnement : accès aux instances liées au contrôle de la façon dont l'environnement est affiché
- Événement distant : accès aux instances pour les opérations de réseau interne
Il y a aussi des instances qui sont disponibles sans capacité en plus d'être en mesure d'exécuter les scripts. Cela inclut les méthodes suivantes HttpService :
Si une propriété ou une méthode d'instance est accessible sans une capacité requise, une erreur est signalée décrivant la capacité manquante.
Enfin, les capacités ne couvrent pas toutes les instances dans le moteur Roblox aujourd'hui. Les instances non listées dans cette section ou la suivante ne sont pas disponibles pour l'interaction à partir d'un conteneur sandboxé et lance une erreur en disant qu'une capacité non attribuée n'est pas disponible pour le script actuel.
Une autre limitation est que getfenv et setfenv les fonctions ne sont pas disponibles pour les scripts dans un conteneur sandboxé.
L'accès aux scripts aux instances est limité. Les instances elles-mêmes peuvent toujours exister et fonctionner par elles-mêmes dans un conteneur sandboxé. Les lumières brillent toujours, les interfaces de l'utilisateur sont toujours visibles et les paramètres audio qui sont déjà câblés jouent des sons.
Capacités de l'API du moteur
Voici la liste des instances et des méthodes (si différent de la capacité de l'instance) pour chaque capacité d'API du moteur :
Basique * Attachment
- Class.Part , MeshPart , CornerWedgePart , 0> Class.TriangleMeshPart0> , 3> Class.WedgePart3> , Part6>
Audio * AudioAnalyzer ,
Stockage de données * DataStore , OrderedDataStore , GlobalDataStore
- Class.DataStoreGetOptions , DataStoreIncrementOptions , DataStoreInfo , 0> Class.DataStoreKey0> , DataStoreGetOptions3> , 6> Class.DataStoreObjektVersionInfo
Réseau * Class.HttpService:GetAsync , HttpService:RequestAsync() , HttpService:PostAsync() , 0> Class.HttpService:UrlEncode0> , HttpService:GetAsync()3>
Physique * AlignOrientation , AlignPosition , DynamicRotate
UI * BasePlayerGui , PlayerGui , BillboardGui , 0> Class.GuiBase0> ,
- Class.TDM , TextButton , TextFilterResult , 0> Class.TextFilterTranslatedResult0> , 3> Class.TextLabel3> , 6> Class.TextService6> , TextBox9>
- Class.UIComponent , UICorner , UIDragDetector , 0> Class.UIFlexItem0> , 3> Class.UIGradient
CSG * GeometryService
- BasePart méthodes : BasePart:IntersectAsync() , BasePart:SubtractAsync() , 0> Class.BasePart:UnionAsync0>
- Class.IntersectOperation (exige également Basic ), NegateOperation (exige également 0>Basic0>>, 3> Class.PartOperation3> (exige également 6>Basic6>, IntersectOperation9> (exige également IntersectOperation2>), 1> Class.UnionOperation
Chattez. * BubbleChatConfiguration , BubbleChatMessageProperties
- Class.TextChannel , TextChatCommand , TextChatConfigurations , 0> Class.TextChatMessage0> , 3> Class.TextChatMessageProperties3> , 6> Class.TextChatService6> , TextChannel9>
Animation * Bone (requiert également Basic )
- Class.Animation , AnimationClip , AnimationClipProvider , 0> Class.AnimationContainer0> , 3> Class.AnimationRigData3> , 6> Class.AnimationTrack6> , Animation9>
Avatar * Accessory , AccessoryDescription
Environnement * Atmosphere , Clouds , Lighting , 0> Class.Sky0>
- Class.BloomEffect , BlurEffect , ColorCorrectionEffect , 0> Class.ColorGradingEffect0> , 3> Class.DepthOfFieldEffect3> , 6> Class.PostEffect6> , BloomEffect9>
Événement distant * BaseRemoteEvent , RemoteEvent , UnreliableRemoteEvent
Interactions entre les conteneurs
Conteneurs imbriqués
Lorsqu'un conteneur de sandbox est imbriqué dans un autre conteneur, les instances du conteneur interne sont accessibles à l'extérieur.
Les capacités du conteneur interne sont limitées par les capacités du conteneur extérieur. Par exemple, si le conteneur extérieur a des capacités de base, audio et CSG, alors que le conteneur interne a 2> base2> et 5> réseau5>, seuls les capacités de 8> base8> sont disponibles pour le conteneur à l'exécution.
Si il n'y a pas de capacités en commun entre les conteneurs intérieur et extérieur, le ensemble de capacités résultant est vide.
Fonctions et événements liables
BindableEvent et BindableFunction fournissent la meilleure façon de communiquer avec le conteneur ou de permettre qu'il exécute des rappels avec des capacités qu'il n'est pas autorisé à utiliser directement.
Lorsqu'un événement ou une fonction est déclenché, les connexions sont exécutées dans le contexte de la fonction qui les a enregistrées. Cela signifie que si l'événement ou le rappel de fonction est enregistré par le conteneur de sandbox, il est appelé avec les capacités de ce conteneur. Si le rappel est enregistré par le code à l'extérieur, lorsque les scripts de conteneur invoquent-ils, ils exécutent vos fonctions avec des capacités disponibles pour vos fonctions.
Il est important de noter que même avec la capacité accès en dehors d'écrire , les scripts dans les conteneurs sandboxés ne peuvent pas invoquer d'événements ou de fonctions en dehors de leurs conteneurs s'ils ont un ensemble de capacité plus grand que le conteneur lui-même.
Exige un module
Inner ModuleScripts peut être requis par le conteneur de sandbox comme d'habitude. Cependant, si l'instance cible est en dehors du conteneur, le ModuleScript ne peut être requis que si le jeu de capacités qui est disponible pour elle est plus petit ou équal à les capacités disponibles pour le conteneur.
Cette limite ne s'applique pas à RunClientScript et RunServerScript capacités. Si le ModuleScript est placé dans un conteneur avec seulement 1> RunClientScript1> mais est requis d'un script qui a la capacité 4> RunServerScript4>, il est autorisé à réussir et exécuter ces fonctions sur le serveur.
Fonctions appelées directement
Si un ModuleScript dans un conteneur sandboxé est requis de l'extérieur du conteneur, certaines des protections ne sont pas disponibles. En particulier, la fonction cible est capable d'accéder à toutes les instances disponibles pour le caller. Si le caller n'est pas dans un conteneur sandboxé, le call agit comme si AccessOutsideWrite était disponible pour lui.
D'autres restrictions de capacité s'appliquent toujours. Si vous avez une capacité d'accès DataStore mais que le module cible ne l'a pas, il n'est pas capable d'appeler les méthodes DataStore. Cependant, si vous passez votre propre fonction fonctionnant avec DataStore, le module cible peut l'exécuter
Les instances peuvent être passées au module cible ou attribuées aux champs de module.
Si nécessaire, il est recommandé d'assigner des membres de table à l'aide de rawset pour éviter d'exécuter des métodes métiers __index / __newindex sur la table.
La recommandation générale est de communiquer avec BindableEvent et BindableFunction quand c'est possible.
Déplacement des instances
La plupart des instances n'ont pas de restrictions sur le mouvement entre les conteneurs. Les instances de script, cependant, ne peuvent être déplacées que dans un conteneur qui a le même ensemble de capacités ou un sous-ensemble de ces capacités.
Cela signifie que le conteneur de sandbox avec AccessOutsideWrite ne peut pas simplement re- parent un script à l'intérieur de lui-même à l'extérieur et obtenir plus de capacités.