Capabilidades do Script

*Este conteúdo é traduzido por IA (Beta) e pode conter erros. Para ver a página em inglês, clique aqui.

Script Capilities é um sistema que oferece controle sobre ações que scripts podem executar dentro da sub-árvore Class.DataModel . Ele fornece melhor controle sobre scripts de experiência do que ser um "tudo ou nada" sistema onde qualquer script pode fazer qualquer coisa que outros scripts podem.

  • Este sistema permite que você limite o que modelos da caixa de ferramentas podem fazer e facilita incluir conteúdo gerado pelo usuário dentro da experiência, mesmo aqueles que contêm scripts.
  • Também pode ajudar a garantir melhor segurança de experiências que permitem que os jogadores executem seu próprio código, o que muitas vezes é executado em um ambiente restrito ou emulado.
  • Também pode ser usado para compartilhar bibliotecas que restringem o que eles podem fazer por si mesmos. Por exemplo, uma biblioteca que fornece métodos de matemática adicionais pode ser restrita para o menor conjunto de habilidades que ela precisa para que outros desenvolvedores que usam essa biblioteca não tenham que validar toda a base de código para garantir que não haja código malicioso.

Habilitando Capacidades de Script

Para habilitar essa funcionalidade, altere a configuração SandboxedInstanceMode de Default para Experimental no Explorador.

Quando o teste beta do cliente for concluído, este passo não será mais necessário.

Recipiente Sandboxado

Este sistema introduz um conceito de um conteiner sandboxado . Uma instância de tipo Model , Folder , 1> Class.Script1> ou descendentes de qualquer uma dessas classes têm uma propriedade 4> Class.Instance.Sandboxed

Sandboxed property of a Folder in the Properties window.

Habilitar a propriedade Sandboxed designa a instância como um contêiner sandboxed dentro da árvore DataModel, o que limita as ações que os scripts dentro desse contêiner podem executar com base no conjunto de valores na propriedade Capabilities.

Capabilidades

A propriedade Capabilities é um conjunto de valores que controlam diferentes aspectos da execução, divididos em quatro grupos:

  • Controle de execução - Especifica se um script pode ser executado no cliente ou servidor
  • Controle de acesso à instância - Especifica quais DataModel peças um script pode interagir
  • Controle de funções de script - Especifica quais scripts do Luau podem ser chamados
  • Acesso de controle de API do motor - Especifica quais partes da API do motor do Roblox podem ser usadas

Quando um script tenta executar uma ação que não está no conjunto de habilidades para o estado de execução atual, um erro é relatado. Erros geralmente incluem a ação sendo executada, o alvo de uma ação e a primeira capacidade que está faltando, por exemplo:

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)

Controle de Execução

Este conjunto inclui duas capacidades:

  • RunClientScript - LocalScript ou Script com um valor de 0> Class.BaseScript.RunContext|RunContext0> de 3> Class.EnumerateRunContext 3> é permitido executar no cliente
  • RunServerScript - Script com um valor de RunContext de 0> Class.RunContext.Server|Server0> é permitido executar no servidor

Se o script for Enabled, mas a capacidade correspondente ao local em que ele tenta iniciar não estiver disponível, uma mensagem de aviso é exibida na janela Saída . Se um script não deveria ser executado nesse contexto, desative ou exclua-o.

Nota que ModuleScripts não são necessários para ter essas capacidades de execução para serem necessárias.

Quando um script não consegue iniciar porque a capacidade de controle de execução está faltando, ele é relatado como um aviso na saída, por exemplo:

Cannot start server script 'Script' (lacking capability RunServerScript)

Controle de Acesso à Instância

Este conjunto inclui apenas uma capacidade:

  • Acesso ao EscritoFora da Caixa de Areia - Script é permitido para extrair e receber instâncias do contêiner sandboxado

Quando a capacidade não está disponível, o script só pode procurar instâncias que estão dentro de seu próprio contêiner sandboxado. Por exemplo, se o script for colocado diretamente no contêiner sandboxado, script.Parent.Parent retorna nil.

Além disso, qualquer evento de API do Roblox que passa em um Instance em vez de passar em um nil para qualquer Instance fora do contêiner sandboxado. Por exemplo, se o 2>Class.BasePart.Touched2> for sinalizado por um toque de uma instância fora do contê

Evite configurar essa capacidade; sandboxing garantias são mais fracas quando scripts podem interagir com qualquer instância em uma experiência.

Acesso a Serviços

Mesmo sem AcessoFora daBaú, scripts no contêiner em sandbox ainda podem acessar game, workspace e serviços. Este acesso é fornecido para que scripts ainda possam chamar métodos úteis desses globais, como 2> Class.DataModel.GetService2>, mas o acesso a instâncias filhas ainda é válido.

Instâncias internamente passadas

Se uma instância for passada por uma chamada de função que não passa pelas APIs do Roblox, a referência é preservada. No entanto, se um ModuleScript for passado desta maneira, ele não pode ser requerido sem AcessoFora daEscrita. Isso é porque a retornada do ModuleScript geralmente é mutável e pode ser modificada por

Controle de Funcionalidade do Script

Este conjunto de capacidades controla alguns aspectos gerais dos scripts:

  • AssetRequires - Script é permitido chamar require com um ID de ativo
  • LoadString - Script é permitido chamar loadstring
  • ScriptGlobals - O script tem shared e _G disponíveis
  • CriarInstâncias - Script pode criar novas instâncias usando Instance.new, Instance.fromExisting ou 0> Class.Instance:Clone0>

Mantenha em mente que restrições de função padrão ainda se aplicam. Mesmo que LoadString seja habilitado, a experiência ainda precisa habilitá-lo em ServerScriptService, e ela ainda está disponível apenas no servidor.

Para criar novas instâncias, além de Criar Instâncias , é necessário uma capacidade adicional da API do Motor fornecida por Criar Instâncias Adicionais.

Controle de Acesso à API do Motor

Este último grupo de capacidades controla o acesso de script a várias APIs do Motor:

  • Básico - Acesso a instâncias simples e blocos de construção essenciais
  • Áudio - Acesso a instâncias relacionadas a APIs de áudio
  • Armazenamento de Dados - Acesso a APIs de armazenamento de dados e armazenamento de memória
  • Rede de Redes - Acesso a APIs de rede HTTP
  • Física - Acesso a instâncias relacionadas à física
  • UI - Acesso a instâncias relacionadas a interfaces do usuário
  • CSG : acesso a instâncias e funções relacionadas à geometria sólida construtiva (GSC - Geometria Sólida Construtiva)
  • Chat : acesso a instâncias relacionadas a conversas na experiência
  • Animação : acesso a instâncias relacionadas às animações
  • Avatar : acesso a instâncias relacionadas a avatares
  • Entrada : acesso a instâncias relacionadas à entrada do usuário
  • Ambiente : acesso a instâncias relacionadas ao controle de como o ambiente é exibido
  • Evento Remoto : acesso a instâncias para operações de rede interna

Existem também instâncias que estão disponíveis sem nenhuma capacidade além de serem capazes de executar os scripts. Essas incluem os seguintes métodos HttpService :

Se uma propriedade ou método de instância for acessado sem uma capacidade necessária, um erro é relatado descrevendo a capacidade perdida.

Finalmente, capacidades não cobrem todas as instâncias no motor do Roblox hoje. Instâncias não listadas nesta seção ou na seguinte não estão disponíveis para interação a partir de um contêiner sandboxado e apresentar um erro dizendo que uma capacidade não atribuída não está disponível para o script atual.

Uma limitação adicional é que getfenv e setfenv funções não estão disponíveis para scripts em um contêiner sandboxado.

Apenas o acesso de script a instâncias é limitado. As instâncias em si mesmas ainda podem existir e operar por si mesmas dentro de um contêiner sandboxado. As luzes ainda brilham, as interfaces do usuário ainda são visíveis e as configurações de áudio que já estão conectadas ainda tocam sons.

Capacidades da API do Motor

Aqui está a lista de instâncias e métodos (se diferente da capacidade da instância) para cada capacidade da API do Motor:

Interações entre Contêineres

Contêineres Ninados

Quando um contêiner de sandbox é aninhado em outro, as instâncias do contêiner interno são acessíveis ao externo.

As capacidades do contêiner interno são limitadas pelas capacidades do contêiner externo. Por exemplo, se o contêiner externo tiver capacidades de Básico, Áudio e CSG, enquanto o contêiner interno tiver 2>Básico2> e 5>Rede5>, apenas as capacidades de 8>Básico8> estão disponíveis para o contê

Se não houver capacidades em comum entre os contêineres internos e externos, o conjunto de capacidades resultante é vazio.

Funções e Eventos Vinculáveis

BindableEvent e BindableFunction fornecem a melhor maneira de comunicar-se com o contêiner ou permitir que ele execute chamadas com capacidades que não são permitidas diretamente.

Quando um evento ou uma função é disparado, conexões são executadas no contexto da função que os registrou. Isso significa que se o evento ou a função retornar chamadas, eles são chamados com as capacidades do contêiner de onde foram registrados. Se o evento ou função retornar chamadas, eles são executados com as capacidades disponíveis para suas funções. Se o evento ou função retornar chamadas, eles são executados com as capacidades disponíveis para suas funções.

É importante notar que, mesmo com a capacidade AccessOutsideWrite , scripts em contêineres em sandboxes não podem invocar eventos ou funções fora de seus contêineres se tiverem um conjunto de capacidade maior que o próprio contêiner.

Requerimento de Módulo

O módulo ModuleScripts pode ser exigido pelo contêiner sandboxado como de costume. Se a instância alvo estiver fora do contêiner, o módulo ModuleScript só pode ser exigido se a capacidade disponível for menor ou igual às capacidades disponíveis para o contêiner.

Essa limitação não se aplica às capacidades RunClientScript e RunServerScript. Se o ModuleScript for colocado em um contêiner com apenas 2> RunClientScript2> mas é necessário de um script que tem a capacidade 5> RunServerScript5>, ele é permitido para ter sucesso e executar essas funções no servidor.

Chamadas Diretamente Funções

Se um ModuleScript em um contêiner sandboxado for necessário do lado de fora do contêiner, algumas das proteções não estão disponíveis. Em particular, a função de alvo é capaz de acessar todas as instâncias disponíveis para o usuário. Se o usuário não estiver em um contêiner sandboxado, o chamado atua como se AccessOutsideWrite estivesse disponível para ele.

Outras restrições de capacidade ainda se aplicam. Se você tiver acesso Armazenamento de Dados através de uma capacidade DataStore, mas o módulo de destino não, ele não pode chamar DataStore métodos. No entanto, se você passar sua própria função trabalhando com

Instâncias podem ser passadas para o módulo de destino ou atribuídas aos campos de módulo.

Se necessário, é recomendado atribuir membros de tabela usando rawset para evitar executar métodos de metadados que podem ser definidos na tabela.

A recomendação geral é comunicar com BindableEvent e BindableFunction sempre que possível.

Movimento de Instâncias

A maioria das instâncias não tem restrições sobre o movimento entre contêineres. As instâncias de script, no entanto, só podem ser movidas para um contêiner que tenha o mesmo conjunto de recursos ou um subconjunto desses recursos.

Isso significa que um contêiner de sandbox com AccessOutsideWrite não pode simplesmente re-planejar um script dentro de si mesmo para fora e obter mais capacidades.