Las capacidades de scripts son experimentales y están disponibles como una beta para clientes.
Las capacidades de scripts te permiten controlar qué acciones pueden realizar los scripts dentro del subárbol de DataModel. En lugar del "sistema de todo o nada" por defecto, puedes configurar un script para que solo pueda acceder a ciertas categorías, como audio, física, almacenes de datos y más.
- Este sistema te permite limitar lo que los modelos tomados de la caja de herramientas pueden hacer y facilita incluir contenido generado por los usuarios dentro del juego.
- También puede ayudar a garantizar una mejor seguridad de los juegos que permiten a los jugadores ejecutar su propio código, que a menudo se ejecuta en un entorno restringido o emulado.
- También se puede usar para compartir bibliotecas que restringen lo que pueden hacer por sí mismas. Por ejemplo, una biblioteca que proporciona métodos matemáticos adicionales puede restringirse al conjunto más pequeño de capacidades que necesita, para que otros desarrolladores que usen esa biblioteca no tengan que validar toda la base de código para asegurarse de que no incluya código malicioso.
Habilitar capacidades de scripts
Para habilitar esta función, cambia la propiedad SandboxedInstanceMode de Default a Experimental en la ventana Explorer y Properties.
Contenedor en sandbox
Las capacidades de scripts introducen el concepto de un contenedor en sandbox. Models, Folders, Scripts, o descendientes de cualquiera de esas clases tienen una propiedad Sandboxed disponible en la ventana Properties.
Habilitar la propiedad Sandboxed designa la instancia como un contenedor en sandbox dentro del árbol de DataModel, lo que limita las acciones que los scripts dentro de ese contenedor pueden realizar en base al conjunto de valores en la propiedad Capabilities.
Capacidades
La propiedad Capabilities es un conjunto de valores que controlan diferentes aspectos de la ejecución. Las capacidades se dividen en las siguientes categorías generales:
- Control de ejecución - Especifica si un script puede ejecutarse en el cliente o el servidor
- Control de acceso a instancias - Especifica qué partes de DataModel puede interactuar un script
- Control de funcionalidad del script - Especifica qué funciones de Luau pueden llamar los scripts
- Control de acceso a la API del motor - Especifica qué partes de la API del motor de Roblox pueden ser utilizadas
Cuando un script intenta realizar una acción que no está en el conjunto de capacidades, Roblox informa un error. Los errores típicamente incluyen la acción que se intenta, el objetivo de la acción y la primera capacidad que falta:
Control de ejecución
Dos capacidades manejan el control de ejecución:
- RunClientScript - LocalScript o Script con un valor de RunContext de Client está permitido ejecutar en el cliente
- RunServerScript - Script con un valor de RunContext de Server está permitido ejecutar en el servidor
Si el script está Enabled, pero la capacidad correspondiente a la ubicación en la que intenta comenzar no está disponible, se muestra un mensaje de advertencia en la ventana Output. Si un script no debía ejecutarse en ese contexto, desactívalo o elimínalo.
Ten en cuenta que ModuleScripts no necesitan tener estas capacidades de ejecución para ser requeridos.
Cuando un script falla al iniciar porque la capacidad de control de ejecución falta, se informa como una advertencia en la salida, por ejemplo:
Control de acceso a instancias
Una sola capacidad maneja el control de acceso a instancias:
- AccessOutsideWrite - Se permite al script obtener y recibir instancias desde fuera del contenedor en sandbox
Cuando la capacidad no está disponible, el script solo puede buscar instancias que están dentro de su propio contenedor en sandbox. Por ejemplo, si el script se coloca directamente en el contenedor en sandbox, script.Parent.Parent devuelve nil.
Además, cualquier evento de la API de Roblox que pase una Instance en su lugar pasa nil para cualquier Instance fuera del contenedor en sandbox. Por ejemplo, si BasePart.Touched es activado por un toque de una instancia fuera del contenedor en sandbox, el evento sigue siendo recibido, pero el argumento es nil.
Evita establecer esta capacidad; las garantías de sandboxing son más débiles cuando los scripts pueden interactuar con cualquier instancia en un juego.
Acceso a servicios
Incluso sin AccessOutsideWrite, los scripts en el contenedor en sandbox aún pueden acceder a game, workspace, y servicios. Este acceso se proporciona para que los scripts aún puedan llamar a métodos útiles de esos globales, como DataModel.GetService, pero el acceso a sus instancias secundarias aún es validado.
Instancias pasadas internamente
Si una instancia es pasada a través de una llamada a función que no pasa por las APIs de Roblox, la referencia se preserva. Sin embargo, si un ModuleScript se pasa de esta manera, no se puede requerir sin AccessOutsideWrite. Esto se debe a que el retorno del ModuleScript es a menudo mutable y puede ser modificado por un script en un contenedor en sandbox.
Control de funcionalidad del script
Este conjunto de capacidades controla algunos aspectos generales de los scripts:
- CreateInstances - El script puede crear nuevas instancias utilizando Instance.new, Instance.fromExisting, o Instance:Clone()
- LoadString - Se permite al script llamar a loadstring
- LoadUnownedAsset - Se permite al script llamar a require con un ID de activo o AssetService:LoadAssetAsync()
Ten en cuenta que las restricciones de funciones predeterminadas aún se aplican. Incluso si LoadString está habilitado, el juego aún tiene que habilitarlo en ServerScriptService, y sigue estando disponible solo en el servidor.
Para crear nuevas instancias, además de CreateInstances, se requiere una capacidad adicional de la API del motor que brinde 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 APIs del motor:
- Animation - Acceso a instancias relacionadas con animaciones
- AssetCreateUpdate - Acceso a APIs del motor relacionadas con la creación o actualización de activos
- AssetManagement - Acceso a APIs del motor relacionadas con operaciones sobre activos que no sean lectura, creación o actualización
- AssetRead - Acceso a APIs del motor relacionadas con obtener información sobre activos
- Audio - Acceso a instancias relacionadas con APIs de audio
- AvatarAppearance - Acceso a instancias relacionadas con los elementos visuales de los avatares
- AvatarBehavior - Acceso a APIs del motor relacionadas con controlar o modificar el humanoide
- Basic - Acceso a APIs generales que ofrecen poco riesgo
- CSG - Acceso a instancias y funciones relacionadas con geometría sólida constructiva (CSG)
- CapabilityControl - Acceso a modificar las propiedades Sandboxed y Capabilities de las instancias
- Capture - Acceso a APIs del motor relacionadas con capturar capturas de pantalla o videos en la pantalla del usuario
- Chat - Acceso a instancias relacionadas con el chat en el juego
- Consequences - Acceso a APIs para castigar a los usuarios (expulsiones o prohibiciones)
- DataStore - Acceso a APIs de almacenes de datos y almacenes de memoria
- DynamicGeneration - Acceso a APIs del motor relacionadas con la modificación dinámica de activos
- Environment - Acceso a instancias relacionadas con el control de cómo se muestra el entorno
- Groups - Acceso a APIs del motor relacionadas con grupos/comunidades
- Input - Acceso a instancias relacionadas con la entrada del usuario
- LegacySound - Acceso a APIs del motor relacionadas con sonidos que serán descontinuados
- LoadOwnedAsset - Acceso a APIs del motor para cargar activos que son de tu propiedad, compartidos contigo, propiedad de Roblox, o son un tipo de activo benigno
- Logging - Acceso a la API de registros
- Material - Acceso a APIs del motor relacionadas con materiales
- Monetization - Acceso a APIs del motor relacionadas con monetizar un juego, excluyendo la mayoría de PromptPurchases
- Network - Acceso a APIs de red HTTP
- Physics - Acceso a instancias relacionadas con la física
- PlatformAvatarEditing - Acceso a APIs del motor relacionadas con la creación o actualización de avatares, o APIs para ayudar con eso
- Players - Acceso a APIs del motor relacionadas con la clase Player o que devuelven/interactúan con Players.LocalPlayer
- PromptExternalPurchase - Permite el acceso a APIs del motor relacionadas con la solicitud de compra de activos arbitrarios
- RemoteEvent - Acceso a instancias para operaciones de red internas
- SensitiveInput - Acceso a APIs del motor relacionadas con la captura de entrada sensible del usuario, es decir, sensores de hardware de alta privacidad.
- ServerCommunication - Acceso a APIs del motor relacionadas con la comunicación entre servidores, como MessagingService
- Social - Acceso a APIs del motor relacionadas con características sociales, como amigos e invitaciones
- Teleport - Acceso a APIs del motor relacionadas con teletransportes
- UI - Acceso a instancias relacionadas con interfaces de usuario
Las capacidades de cada clase, propiedad, método y evento se muestran en la referencia API del motor. Por ejemplo, Player:GetFriendsOnlineAsync() requiere las capacidades Player y Social.
Varios métodos de HttpService están disponibles sin ninguna capacidad, aparte de poder ejecutar los scripts:
Si se accede a una propiedad o método de instancia sin una capacidad requerida, se informa un error que describe la capacidad que falta.
Finalmente, las capacidades no cubren cada instancia en el motor de Roblox hoy. Las instancias no listadas en esta sección o en la siguiente no están disponibles para interacción desde un contenedor en sandbox y lanzan un error diciendo que una capacidad No asignada no está disponible para el script actual.
Una limitación adicional es que las funciones getfenv() y setfenv() no están disponibles para scripts en un contenedor en sandbox. Llamarlas desde un script en sandbox informa:
Solo se limita el acceso del script a las instancias. Las instancias en sí mismas pueden seguir existiendo y operando por sí solas dentro de un contenedor en sandbox. Las luces siguen brillando, las interfaces de usuario siguen siendo visibles y las configuraciones de audio que ya están cableadas reproducen sonidos.
Interacciones entre contenedores
Contenedores anidados
Cuando un contenedor en sandbox está anidado dentro de otro, las instancias del contenedor interno son accesibles para el externo.
Las capacidades del contenedor interno están limitadas por las capacidades del externo. Por ejemplo, si el contenedor externo tiene capacidades de Basic, Audio y CSG, mientras que el contenedor interno tiene Basic y Network, solo las capacidades Basic están disponibles para el contenedor interno en tiempo de ejecución.
Si no hay capacidades en común entre los contenedores interno y externo, 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 este ejecute callbacks con capacidades que él mismo no tiene permitidas usar directamente.
Cuando se dispara un evento o se invoca una función, las conexiones se ejecutan en el contexto de la función que las registró. Esto significa que si el evento o la devolución de llamada de la función es registrada por el contenedor en sandbox, se llama con las capacidades de ese contenedor. Si la devolución de llamada es registrada por el código externo, cuando los scripts del contenedor en sandbox las invocan, ejecutan tus funciones con las capacidades disponibles para tus funciones.
Es importante notar que incluso con la capacidad AccessOutsideWrite, los scripts en contenedores en sandbox no pueden invocar eventos o funciones fuera de sus contenedores si tienen un conjunto de capacidades más grande que el propio contenedor.
Cuando un script en sandbox intenta disparar o invocar un evento o función (BindableEvent, BindableFunction, o RemoteEvent) cuyas capacidades antecesoras superan las suyas, el error nombra la propiedad que se debe inspeccionar.
Si el objetivo no está dentro de ningún contenedor en sandbox:
Para resolver esto, establece Sandboxed en true para el objetivo. Alternativamente, puedes modificar el origen del hilo que llama para que tenga Sandboxed establecido en false, pero esto no se recomienda ya que elimina los beneficios de seguridad que proporciona el sandboxing.
Si el objetivo está en sandbox pero tiene capacidades que el llamador carece:
Para resolver esto, reduce las Capabilities del objetivo a un subconjunto de las del llamador, o expande las Capabilities del llamador para que coincidan con las del objetivo.
Requerir módulos
Los ModuleScripts internos pueden ser requeridos por el contenedor en sandbox como de costumbre. Sin embargo, si la instancia de destino está fuera del contenedor, el ModuleScript solo puede ser requerido si el conjunto de capacidades que tiene disponible es menor o igual a las capacidades disponibles para el contenedor.
Esta limitación no se aplica a las capacidades RunClientScript y RunServerScript. Si el ModuleScript se coloca en un contenedor con solo RunClientScript pero se requiere desde un script que tiene la capacidad RunServerScript, se permite que tenga éxito y ejecute esas funciones en el servidor.
Cuando require() falla por un desacuerdo de capacidades, el error nombra el módulo objetivo y la propiedad a inspeccionar de la misma manera que las funciones y eventos vinculables descritos en la sección anterior.
Funciones llamadas directamente
Si un ModuleScript en un contenedor en sandbox es requerido desde fuera del contenedor, algunas de las protecciones no están disponibles. En particular, la función objetivo puede acceder a todas las instancias disponibles para el llamador. Si el llamador no está en un contenedor en sandbox, la llamada actúa como si AccessOutsideWrite estuviera disponible para él.
Sin embargo, aún se aplican otras restricciones de capacidades. Si tienes una capacidad de acceso a DataStore, pero el módulo objetivo no, no podrá llamar a los métodos DataStore. Sin embargo, si pasas tu propia función que trabaja con DataStore, el objetivo puede ejecutarla durante esa llamada. Si el objetivo programa un hilo utilizando métodos como los de task, esos hilos pierden la capacidad de llamar a esa función.
Las instancias pueden ser pasadas al módulo objetivo o asignadas a los campos del módulo.
Si es necesario, se recomienda asignar miembros de la tabla utilizando rawset para evitar la ejecución de los metamétodos __index/__newindex que podrían estar configurados en la tabla.
La recomendación general es comunicarse usando BindableEvent y BindableFunction siempre que sea posible.
Movimiento de instancias
La mayoría de las instancias no tienen restricciones sobre el movimiento entre contenedores. Sin embargo, las instancias de script solo pueden ser movidas a un contenedor que tenga el mismo conjunto de capacidades o un subconjunto de esas capacidades.
Esto significa que un contenedor en sandbox con AccessOutsideWrite no puede simplemente re-parentar un script dentro de sí mismo hacia afuera y obtener más capacidades.