Script Capilities es un sistema que ofrece control sobre las acciones que los scripts pueden realizar dentro del subárbol DataModel. Proporciona mejores controles para los scripts de experiencia en lugar de ser un sistema "todos o nada" donde cualquier script puede hacer cualquier cosa que otros scripts pueden.
- Este sistema le permite limitar lo que los modelos tomados de la caja de herramientas pueden hacer y hace más fácil incluir el contenido generado por usuarios dentro de la experiencia, incluso aquellos que contienen scripts.
- También puede ayudar a garantizar una mejor seguridad de las experiencias que permiten a los jugadores ejecutar su propio código, que a menudo se ejecuta en un entorno, ambienterestringido o emulado.
- También se puede usar para compartir bibliotecas que restringen lo que pueden hacer ellos mismos. Por ejemplo, una biblioteca que proporciona métodos de matemática adicionales puede ser restringida al menor conjunto de capacidades que necesita para que otros desarrolladores que usan esa biblioteca no tengan que validar todo el código base para asegurarse de que no incluya código malicioso.
Habilitando Capacidades de Script
Para habilitar esta función, cambie la configuración de SandboxedInstanceMode desde Default a Experimental en el Explorador.
Cuando se complete la beta del cliente, ya no se requerirá este paso.
Contenedor de Sandbox
Este sistema introduce un concepto de un contenedor de contenedor de arena . Una instancia de tipo Model , Folder , 1> Class.Script1> , o descendientes de cualquiera de esas clases tienen una propiedad 4> Class.Instance.Sandbox
Activar la propiedad Sandboxed designa la instancia como un contenedor de arena dentro del árbol DataModel, lo que limita las acciones que los scripts dentro de ese contenedor pueden realizar según el conjunto de valores en la propiedad Capabilities.
Capabilidades
La propiedad Capabilities es un conjunto de valores que controlan diferentes aspectos de la ejecución, divididos en cuatro grupos:
- Control de ejecución - Especifica si un script se puede ejecutar en el cliente o el servidor
- Control de acceso a la instancia - Especifica con qué DataModel partes un script puede interactuar
- Funciones de control de scripts - Especifica qué scripts de Luau pueden llamar
- Acceso de API de motor para controlar - Especifica qué partes de la API del motor de Roblox se pueden usar
Cuando un script intenta realizar una acción que no está en el conjunto de capacidades para el estado de ejecución actual, se informa un error. Los errores generalmente incluyen la acción que se está intentando, el objetivo de una acción y la primera capacidad que se ha perdido, por ejemplo:
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)
Control de ejecución
Este conjunto incluye dos capacidades:
- EjecutarClientScript - LocalScript o Script con un valor de 0> Class.BaseScript.RunContext|RunContext0> de 3> Class.Enumerate.RunContext 3> en el cliente
- EjecutarScript del servidor - Script con un valor de RunContext de 0> Encuentro.RunContext.Server|Server0> es permitido para ejecutarse en el servidor
Si el script es Enabled , pero la capacidad que coincide con la ubicación en la que intenta iniciar no está disponible, se muestra un mensaje de advertencia en la ventana Salida . Si un script no estaba destinado a ser ejecutado en ese contexto, desactivarlo o eliminarlo.
Nota que ModuleScripts no son requeridos para tener estas capacidades de ejecución para ser requeridas.
Cuando un script no se puede iniciar porque se ha perdido la capacidad de control de ejecución, se informa como una advertencia en la Salida, por ejemplo:
Cannot start server script 'Script' (lacking capability RunServerScript)
Control de acceso a la instancia
Este conjunto solo incluye una capacidad:
- Acceso fuera de la escritura exterior - Se permite que el script obtenga y reciba instancias desde el contenedor de arena
Cuando la capacidad no está disponible, el script solo puede buscar instancias que estén dentro de su propio contenedor de arena. Por ejemplo, si el script se coloca directamente en el contenedor de arena, nil devuelve nil .
Además, cualquier evento de API de Roblox que se activa en un Instance en lugar se activa en un nil para cualquier Instance fuera del contenedor de prueba. Por ejemplo, si el 2>Class.BasePart.Touched2> es señalado por un toque desde un instante fuera del contenedor de
Evite configurar esta capacidad; los garantías de sandboxing son más débiles cuando los scripts pueden interactuar con cualquier instancia en una experiencia.
Acceso a los servicios
Aún sin AccessOutsideWrite , los scripts en el contenedor de arena todavía pueden acceder a game , workspace y servicios. Este acceso se proporciona para que los scripts todavía puedan llamar métodos útiles de esos globales, como 1> Class.DataModel.GetService1> , pero el acceso a sus instancias de hijos todavía se valida.
Instancias internamente pasadas
Si se pasa una instancia a través de una función que no pasa a través de las API de Roblox, se mantiene la referencia. Sin embargo, si un ModuleScript se pasa de esta manera, no se puede requerir sin Acceso fuera de escribir . Esto se debe a que el retorno del ModuleScript es a menudo mutable y se puede modificar por un script en un contenedor de
Control de Funcionalidad del Script
Este conjunto de capacidades controla algunos aspectos generales de los scripts:
- AssetRequirement - Script está permitido llamar a require con un ID de activo
- LoadString - Se permite que el script llame a loadstring
- CrearInstancias - El script puede crear nuevas instancias usando Instance.new, Instance.fromExisting o 0> Class.Instance:Clone0>
Tenga en cuenta que las limitaciones de función predeterminadas siguen aplicando. Incluso si se habilita Cargar Cuerda , la experiencia todavía tiene que habilitarlo en ServerScriptService , y solo está disponible en el servidor.
Para crear nuevas instancias, aparte de CrearInstancias , se requiere una capacidad de API de Motor adicional que proporcione acceso a esa instancia.
Control de acceso a la API del motor
Este último grupo de capacidades controla el acceso de los scripts a varias API del motor:
- Básico - Acceso a instancias simples y bloques de construcción esenciales
- Audio - Acceso a instancias relacionadas con las API de audio
- Almacén de datos - Acceso a almacén de datos y API de almacén de memoria
- Red - Acceso a las interfaces de red HTTP
- Física - Acceso a instancias relacionadas con la física
- UI - Acceso a instancias relacionadas con las interfaces de usuario
- CSG : acceso a instancias y funciones relacionadas con geometría sólida constructiva (Geometría constructiva de sólidos)
- Chat : acceso a instancias relacionadas con el chat en la experiencia
- Animación : acceso a instancias relacionadas con las animaciones
- Avatar : acceso a instancias relacionadas con los avatares
- Entrada : acceso a instancias relacionadas con la entrada del usuario
- Entorno : acceso a instancias relacionadas con el control de cómo se muestra el entorno
- Evento remoto : acceso a instancias para operaciones de red interna
También hay instancias que están disponibles sin ninguna capacidad aparte de poder ejecutar los scripts. Estas incluyen los siguientes métodos de HttpService :
Si se accede a una propiedad o método de instancia sin una capacidad requerida, se informa un error que describe la capacidad que se ha perdido.
Finalmente, las capacidades no cubren todas las instancias en el motor de Roblox hoy. Las instancias no listadas en esta sección o la siguiente no están disponibles para la interacción de un contenedor de prueba y lanzar un error diciendo que no está disponible una capacidad Asignada en el script actual.
Una limitación adicional es que getfenv y setfenv funciones no están disponibles para los scripts en un contenedor de sandbox.
El acceso de solo script a las instancias está limitado. Las instancias mismas aún pueden existir y operar por sí mismas dentro de un contenedor de prueba de arena. Las luces todavía brillan, las interfaces de usuario todavía son visibles y las configuraciones de audio que ya están conectadas emiten sonidos.
Asignaciones de capacidades de la API del motor
Aquí está la lista de instancias y métodos (si es diferente de la capacidad de la instancia) para cada capacidad de API de Motor:
Básico * Attachment
- Class.Part , MeshPart , CornerWedgePart , 0> Class.TriangleMeshPart0> , 3> Class.TrussPart3> , Part6>
Audio * AudioAnalyzer ,
Almacén de datos * DataStore , OrderedDataStore , GlobalDataStore
- Class.DataStoreGetOptions , DataStoreIncrementOptions , DataStoreInfo , 0> Class.DataStoreKey0> , 3> Class.DataStoreKeyInfo3> , DataStoreGetOptions6> ,
Red de trabajo * Class.HttpService:GetAsync , HttpService:RequestAsync() , HttpService:PostAsync() , 0> Class.HttpService:Encapsule0> , HttpService:GetAsync()3>
Física * AlignOrientation , AlignPosition , DynamicRotate
UI * BasePlayerGui , PlayerGui , BillboardGui , 0> Class.GuiBase0> ,
- Class.Toolbar , 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étodos: BasePart:IntersectAsync() , BasePart:SubtractAsync() , 0> Class.BasePart:UnionAsync0>
- Class.IntersectOperation (también requiere Haz básico ), NegateOperation (también requiere 0>Haz básico0>), 3> Class.PartOperation3> (también requiere 6>Haz básico6>), IntersectOperation9> (también
Chat * BubbleChatConfiguration , BubbleChatMessageProperties
- Class.TextChannel , TextChatCommand , TextChatConfigurations , 0> Class.TextChatMessage0> , 3> Class.TextChatMessageProperties3> , 6> Class.TextChatService6> , TextChannel9>
Animación * Bone (también requiere Haz básico )
- Class.Animation , AnimationClip , AnimationClipProvider , 0> Class.AnimationContainer0> , 3> Class.AnimationRigData3> , 6> Class.AnimationTrack6> , Animation9>
Avatar * Accessory , AccessoryDescription
Entorno * Atmosphere , Clouds , Lighting , 0> Class.Sky0>
- Class.BloomEffect , BlurEffect , ColorCorrectionEffect , 0> Class.ColorGradingEffect0> , 3> Class.DepthOfFieldEffect3> , 6> Class.PostEffect6> , BloomEffect9>
Evento remoto * BaseRemoteEvent , RemoteEvent , UnreliableRemoteEvent
Interacciones entre contenedores
Contenedores de Nesting
Cuando un contenedor de prueba está anidado dentro de otro, las instancias del contenedor interior son accesibles al exterior.
Las capacidades del contenedor interior están limitadas por las capacidades del contenedor exterior. Por ejemplo, si el contenedor exterior tiene capacidades de audio básico, almacenamiento básico y CSG, mientras que el contenedor interior tiene 2>almacenamiento básico2> y 5>red de trabajo5>, solo las capacidades de 8>almacenamiento básico8> est
Si no hay capacidades en común entre los contenedores interiores y exteriores, el conjunto de capacidades resultante está vacío.
Funciones y eventos vinculables
BindableEvent y BindableFunction proporcionan la mejor manera de comunicarse con el contenedor o permitir que se ejecuten llamadas con capacidades que no está permitido directamente.
Cuando se activa un evento o una función, se ejecutan conexiones en el contexto de la función que las registra. Esto significa que si el evento o la función de llamada se registra por el contenedor de prueba, se invoca con las capacidades de ese contenedor. Si el evento o la función de llamada se registra por el código fuera, cuando los scripts de contenedor de prueba invocan a ellos, se ejecutan sus funciones con capacidades disponibles para sus funciones.
Es importante tener en cuenta que incluso con la capacidad AccessOutsideWrite , los scripts en contenedores de sandbox no pueden invocar eventos o funciones fuera de sus contenedores si tienen un conjunto de capacidad mayor que el propio contenedor.
Requiere módulo
Inner ModuleScripts puede ser requerido por el contenedor de prueba como siempre. Sin embargo, si la instancia objetivo está fuera del contenedor, el ModuleScript solo se puede requerir si el conjunto de capacidades que está disponible para ella es más pequeño o igual que las capacidades disponibles para el contenedor.
Esta limitación no se aplica a las capacidades de RunClientScript y RunServerScript. Si el ModuleScript se coloca en un contenedor con solo 2> RunClientScript2> pero es requerido por un script que tiene la capacidad de 5> RunServerScript 5>, se permite el éxito y el rendimiento de esas funciones en el servidor.
Llamadas directas de funciones
Si un ModuleScript en un contenedor de prueba está requerido desde fuera del contenedor, algunas de las protecciones no están disponibles. En particular, la función de objetivo es capaz de acceder a todas las instancias disponibles para el llamador. Si el llamador no está en un contenedor de prueba, la llamada actúa como si AccessOutsideWrite estuviera disponible para él.
Otras limitaciones de capacidad todavía se aplican. Si tienes una capacidad de almacenamiento de datos DataStore pero el módulo objetivo no lo hace, no se puede llamar a DataStore métodos. Sin embargo, si pasas tu propia función que trabaja con DataStore, el módulo objetivo puede ejecutarlo durante
Las instancias se pueden pasar al módulo objetivo o asignarse a los campos del módulo.
Si es necesario, se recomienda asignar a los miembros de la tabla usando rawset para evitar la ejecución de métodos de mejora de la tabla que podrían ser configurados en la tabla.
La recomendación general es comunicarse con BindableEvent y BindableFunction cuando sea posible.
Movimiento de instancias
La mayoría de las instancias no tienen restricciones en el movimiento entre contenedores. Las instancias de script, sin embargo, solo se pueden mover en un contenedor que tenga el mismo conjunto de capacidades o un subconjunto de esas capacidades.
Esto significa que el contenedor de sandbox con AccessOutsideWrite no puede simplemente re- padre un script dentro de sí mismo para el exterior y obtener más capacidades.