Capacités de script

Capacités de script est un système qui offre le contrôle des actions que les scripts peuvent effectuer à l'intérieur du DataModel sous-arbre.Il fournit un meilleur contrôle des 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 puissent faire.

• Ce système vous permet de limiter ce que les modèles extraits de la boîte à outils peuvent faire et facilite l'inclusion du contenu généré par l'utilisateur 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, qui est souvent exécuté dans un environnement restreint ou émulé.
• 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 fournissant des méthodes mathématiques supplémentaires peut être restreinte au plus petit ensemble de capacités dont elle a besoin afin que les autres développeurs utilisant cette bibliothèque n'aient pas à valider l'ensemble du code source pour s'assurer qu'il n'inclut pas de code malveillant.

Activer les capacités de script

Pour activer cette fonctionalité, modifiez la SandboxedInstanceMode de Default à Experimental dans l'Explorer.

Lorsque le test bêta du client est terminé, cette étape ne sera plus requise.

Conteneur sandboxé

Ce système introduit le concept d'un conteneur sandboxé .Une instance de type Model , Folder , Script ou descendante de l'une de ces classes a une propriété Sandboxed disponible dans la fenêtre Propriétés du studio , dans la section Permissions .

L'activation de la propriété Sandboxed désigne l'instance comme un conteneur sandboxé à l'intérieur du DataModel arbre, ce qui limite les actions que les scripts à l'intérieur de ce conteneur peuvent effectuer en fonction du ensemble de valeurs de la propriété Capabilities.

Capacités

La propriété Capabilities est un ensemble de valeurs qui contrôlent différents aspects de l'exécution, répartis 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 d'accès à l'instance - Spécifie les parties DataModel avec lesquelles un script peut interagir
• Contrôle de la fonctionnalité des scripts - Spécifie les scripts de fonctions Luau que les scripts peuvent appeler
• Contrôle d'accès à l'API du moteur - Spécifie quelles parties de l'API du moteur Roblox peuvent être utilisées

Lorsqu'un script essaie d'effectuer une action qui n'est pas dans le ensemble des 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 d'exécution

Ce jeu comprend deux capacités :

• Exécuter le script client - LocalScript ou Script avec une valeur RunContext de Client est autorisé à s'exécuter sur le client
• Exécuter le script du serveur - Script avec une valeur de RunContext de Server est autorisé à s'exécuter sur le serveur

Si le script est Enabled, mais que la capacité correspondant à l'emplacement dans lequel il essaie de s'exécuter n'est pas disponible, un message d'avertissement est affiché dans la fenêtre Sortie .Si un script n'était pas censé s'exécuter dans ce contexte, désactivez-le ou supprimez-le.

Notez que ModuleScripts n'ont pas besoin d'avoir ces capacités d'exécution pour être requises.

Lorsqu'un script ne parvient pas à démarrer car 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 d'accès à l'instance

Ce jeu comprend une seule capacité :

• Accès extérieur écrit - Le script est autorisé à récupérer et à recevoir des instances en dehors du conteneur sandboxé

Lorsque la capacité n'est pas disponible, le script ne peut rechercher que des instances qui se trouvent dans son propre conteneur sandboxé.Par exemple, si le script est placé directement dans le conteneur sandboxé, script.Parent.Parent retourne nil .

De plus, tout événement de l'API Roblox qui passe dans un Instance passe plutôt dans un nil pour tout Instance en dehors du conteneur sandboxé.Par exemple, si le BasePart.Touched est signalé par un toucher d'une instance en dehors du conteneur sandboxé, l'événement est toujours reçu, mais l'argument est nil .

Évitez de définir 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 extérieur écrit , les scripts dans le conteneur 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 DataModel.GetService , mais l'accès à leurs instances enfants est toujours vérifié.

Instances internement transmises

Si une instance est transmise par l'intermédiaire d'un appel de fonction qui ne passe pas par les API de Roblox, la référence est conservée.Cependant, si un ModuleScript est passé de cette manière, il ne peut pas être requis sans Accès extérieur écrit .C'est parce que le retour du ModuleScript est souvent mutable et peut être modifié par un script dans un conteneur en sandbox.

Contrôle de la fonctionnalité des scripts

Ce jeu de capacités contrôle certains aspects généraux des scripts :

• Exigence de ressources - Le script est autorisé à appeler require avec un ID de ressource
• Charger la chaîne - Le script est autorisé à appeler loadstring
• ScriptGlobals - Le script a et disponible
• Créer des instances - Le script peut créer de nouvelles instances en utilisant Instance.new, Instance.fromExisting ou Instance:Clone()

Gardez à l'esprit que les restrictions de fonction par défaut s'appliquent toujours.Même si Charger la chaîne est activé, l'expérience doit toujours être activée dans ServerScriptService et elle n'est toujours disponible que sur le serveur.

Pour créer de nouvelles instances, en plus de Créer des instances , une capacité d'API moteur supplémentaire fournissant un accès à cette instance est requise.

Contrôle d'accès à l'API du moteur

Ce dernier groupe de capacités contrôle l'accès au script à différentes interfaces de moteur :

• Basique - Accès à des instances simples et à des blocs de construction essentiels
• Audio - Accès aux instances liées aux API audio
• Magasin de données - Accès aux API de magasin de données et de 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 relatives aux interfaces utilisateur
• CSG : accès aux instances et aux fonctions relatives à la géométrie solide constructive (géométrie de construction des solides)
• Discussion : 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 aucune capacité en plus d'être en mesure d'exécuter les scripts.Ceux-ci incluent les méthodes suivantes HttpService :

• HttpService:JSONDecode()
• HttpService:JSONEncode()
• HttpService:GenerateGUID()

Si une propriété ou une méthode d'instance est accédée sans 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 répertoriées dans cette section ou dans la suivante ne sont pas disponibles pour l'interaction à partir d'un conteneur sandboxé et lancent une erreur indiquant qu'une capacité non attribuée non attribuée n'est pas disponible pour le script actuel.

Une limitation supplémentaire est que getfenv et setfenv les fonctions ne sont pas disponibles pour les scripts dans un conteneur en sandbox.

Seulement l'accès des scripts aux instances est limité.Les instances elles-mêmes peuvent encore exister et fonctionner par elles-mêmes dans un conteneur sandboxé.Les lumières brillent toujours, les interfaces utilisateur sont toujours visibles et les installations audio déjà câblées produisent des sons.

Attributions de capacité de l'API du moteur

Voici la liste des instances et des méthodes (si différentes de la capacité d'instance) pour chaque capacité d'API moteur :

• Basique * Attachment

  • Beam , ParticleEmitter , Smoke , Sparkles , Trail
  • SurfaceAppearance , Decal , FaceInstance , Texture
  • Light , PointLight , SpotLight
  • Part , MeshPart , CornerWedgePart , TriangleMeshPart , TrussPart , WedgePart
  • FloatCurve , RotationCurve , EulerRotationCurve , Vector3Curve
  • Tween , TweenService
  • Wire
  • WorldModel
  • CollectionService , Debris , RunService

• Audio * AudioAnalyzer , AudioChorus , AudioCompressor , AudioDistortion , AudioEcho , AudioEqualizer , AudioFader , AudioFader , AudioFilter , AudioFlanger , AudioLimiter , AudioPitchShifter , AudioReverb

  • AudioEmitter , AudioPlayer
  • AudioDeviceOutput , AudioListener

• Magasin de données * DataStore , OrderedDataStore , GlobalDataStore

  • DataStoreService , MemoryStoreService
  • DataStoreGetOptions , DataStoreIncrementOptions , DataStoreInfo , DataStoreKey , DataStoreKeyInfo , DataStoreObjectVersionInfo , DataStoreOptions , DataStoreSetOptions
  • MemoryStoreHashMap , MemoryStoreQueue , MemoryStoreSortedMap

• Réseau * HttpService:GetAsync() , HttpService:RequestAsync() , HttpService:PostAsync() , HttpService:UrlEncode() , HttpService:GetSecret()

• Physique * AlignOrientation , AlignPosition , DynamicRotate

  • JointInstance , Motor , Motor6D
  • AngularVelocity , LinearVelocity , LineForce , Torque , VectorForce
  • Weld
  • Constraint , BallSocketConstraint , CylindricalConstraint , HingeConstraint , NoCollisionConstraint , PlaneConstraint , PrismaticConstraint , RigidConstraint , RodConstraint , RopeConstraint , SlidingBallConstraint , SpringConstraint , TorsionSpringConstraint , UniversalConstraint , WeldConstraint

• UI * BasePlayerGui , PlayerGui , BillboardGui , GuiBase , GuiBase2d , GuiBase3d , LayerCollector , ScreenGui , SurfaceGui , SurfaceGuiBase , UIBase

  • CanvasGroup , Frame , ScrollingFrame
  • GuiButton , GuiLabel , GuiObject , ImageButton , ImageLabel
  • Dialog , DialogChoice , ProximityPrompt
  • TextBox , TextButton , TextFilterResult , TextFilterTranslatedResult , TextLabel , TextService , GetTextBoundsParams
  • Path2D
  • UIComponent , UICorner , UIDragDetector , UIFlexItem , UIGradient , UIGridLayout , UIGridStyleLayout , UILayout , UIListLayout , UIPadding , UIPageLayout , UIScale , UIStroke , UITableLayout
  • UIConstraint , UIAspectRatioConstraint , UISizeConstraint , UITextSizeConstraint
  • VideoFrame , ViewportFrame

• CSG * GeometryService

  • BasePart méthodes: BasePart:IntersectAsync() , BasePart:SubtractAsync() , BasePart:UnionAsync()
  • IntersectOperation (nécessite également Basique ), NegateOperation (nécessite également Basique ), PartOperation (nécessite également Basique ), UnionOperation (nécessite également Basique )

• Discussion * BubbleChatConfiguration , BubbleChatMessageProperties

  • ChannelTabsConfiguration
  • ChatInputBarConfiguration , ChatWindowConfiguration , ChatWindowMessageProperties
  • TextChannel , TextChatCommand , TextChatConfigurations , TextChatMessage , TextChatMessageProperties , TextChatService , TextSource

• Animation * Bone (nécessite également de base )

  • Animation , AnimationClip , AnimationClipProvider , AnimationController , AnimationRigData , AnimationTrack , Animator
  • CurveAnimation
  • FaceControls , IKControl
  • Keyframe , KeyframeMarker , KeyframeSequence
  • MarkerCurve
  • PoseBase , Pose , NumberPose

• Avatar * Accessory , AccessoryDescription

  • Accoutrement , Clothing , Shirt , Pants
  • BaseWrap , WrapDeformer , WrapLayer , WrapTarget
  • BodyColors , BodyPartDescription , CharacterAppearance , ShirtGraphic
  • CharacterMesh
  • Humanoid , HumanoidDescription

• Entrée * GamepadService , KeyboardService , MouseService

  • ContextActionService , TouchInputService , UserInputService
  • InputObject , Mouse , PlayerMouse

• Environnement * Atmosphere , Clouds , Lighting , Sky

  • BloomEffect , BlurEffect , ColorCorrectionEffect , ColorGradingEffect , DepthOfFieldEffect , PostEffect , SunRaysEffect

• Événement distant * BaseRemoteEvent , RemoteEvent , UnreliableRemoteEvent

  • RemoteFunction

Interactions entre conteneurs

Conteneurs hérités

Lorsqu'un conteneur sandboxé est imbriqué à l'intérieur d'un autre, les instances du conteneur interne sont accessibles à l'extérieur.

Les capacités du conteneur interne sont limitées par les capacités de celui extérieur.Par exemple, si le conteneur extérieur a des capacités de base , audio et CSG , alors que le conteneur interne a base et réseau , seules les capacités de base sont disponibles pour le conteneur interne lors de l'exécution.

S'il n'y a pas de capacités en commun entre les conteneurs internes et externes, le jeu de capacités résultant est vide.

Fonctions et événements liés bindables

BindableEvent et BindableFunction fournissent la meilleure façon de communiquer avec le conteneur ou de lui permettre d'exécuter 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 la fonction de rappel est enregistré par le conteneur 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 en sandbox invoquent ceux-ci, ils exécutent vos fonctions avec les capacités disponibles pour vos fonctions.

Il est important de noter que même avec la capacité Accès extérieur écrit , les scripts dans des conteneurs en sandbox ne peuvent pas invoquer d'événements ou de fonctions en dehors de leurs conteneurs s'ils ont un ensemble de capacités plus large que le conteneur lui-même.

Module exiger

L'intérieur ModuleScripts peut être requis par le conteneur 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 disponible est plus petit ou égal aux capacités disponibles pour le conteneur.

Cette limitation ne s'applique pas aux capacités RunClientScript et RunServerScript .Si le ModuleScript est placé dans un conteneur avec seulement RunClientScript mais est requis par un script qui a la capacité RunServerScript , il est autorisé à réussir et à exécuter ces fonctions sur le serveur.

Fonctions appelées directement

Si un ModuleScript dans un conteneur en sable est requis à l'extérieur du conteneur, certaines des protections ne sont pas disponibles.En particulier, la fonction cible peut accéder à toutes les instances disponibles pour l'appelant.Si l'appelant n'est pas dans un conteneur sandboxé, l'appel agit comme si Accès extérieur écrit était disponible pour lui.

D'autres restrictions de capacité s'appliquent toujours.Si vous avez une capacité d'accès à un magasin de données , mais que le module cible ne le fait pas, il ne peut pas appeler de méthodes DataStore.Cependant, si vous passez votre propre fonction travaillant avec DataStore, la cible peut l'exécuter pendant cet appel.Si la cible programme un thread en utilisant des méthodes comme celles de task, ces threads perdent la capacité d'appeler cette fonction.

Les instances peuvent être transmises au module cible ou attribuées aux champs du module.

Si nécessaire, il est recommandé d'assigner des membres de table en utilisant rawset pour éviter d'exécuter __index / __newindex des métaméthodes qui pourraient être définies sur la table.

La recommandation globale est de communiquer avec BindableEvent et BindableFunction chaque fois que cela 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 qu'à l'intérieur d'un conteneur qui a le même ensemble de capacités ou un sous-ensemble de ces capacités.

Cela signifie que le conteneur sandboxé avec Accès extérieur écrit ne peut pas simplement ré-parenter un script à l'intérieur de lui-même vers l'extérieur et obtenir plus de capacités.