Capabilità di script

*Questo contenuto è tradotto usando AI (Beta) e potrebbe contenere errori. Per visualizzare questa pagina in inglese, clicca qui.

Script Capabilities è un sistema che offre il controllo su azioni che gli script possono eseguire all'interno del DataModel subtree. Fornisce un migliore controllo sugli script di esperienza piuttosto che essere un "tutto o niente" sistema in cui qualsiasi script può fare qualsiasi cosa che altri script possono.

  • Questo sistema ti consente di limitare ciò che i modelli prelevati dalla toolbox possono fare e rende più facile includere contenuti generati dagli utenti all'interno dell'esperienza, anche quelli che contengono script.
  • Può anche aiutare a garantire una migliore sicurezza delle esperienze che consentono ai giocatori di eseguire il proprio codice, che viene spesso eseguito in un Ambientelimitato o emulato.
  • Può essere utilizzato anche per condividere le librerie che limitano ciò che possono fare da sole. Ad esempio, una libreria che fornisce metodi matematici aggiuntivi può essere limitata all'insieme più piccolo di capacità di cui ha bisogno in modo che altri sviluppatori che usano quella libreria non debbano verificare l'intera base di codice per assicurarsi che non includa codice dannoso.

Abilitare le capacità dello script

Per abilitare questa Proprietà, cambia il SandboxedInstanceMode impostazione da Default a Experimental nell'esploratore.

Questa fase non sarà più richiesta quando il client beta test sarà completato.

Contenitore sabbioso

Questo sistema introduce un concetto di un cont器 sandboxed . Un'istanza di tipo Model , Folder , 1> Class.Script1> , o discendenti di qualsiasi di queste classi hanno una proprietà 4> Class.Instance.Sandboxed

Sandboxed property of a Folder in the Properties window.

L'abilitazione della proprietà Sandboxed designa l'istanza come un container sandboxed all'interno del DataModel albero, il che limita le azioni che gli script all'interno di quella proprietà possono eseguire in base al set di valori nella ProprietàCapabilities.

Capabilità

La proprietà Capabilities è un insieme di valori che controlla diversi aspetti dell'esecuzione, diviso in quattro gruppi:

  • Controllo di esecuzione - Specifica se uno script può essere eseguito sul client o sul Server
  • Controllo dell'accesso all'istanza - Specifica le parti di DataModel con cui uno script può interagire
  • Controllo della funzionalità dello script - Specifica quali script Luau possono chiamare
  • Controllo accesso API motore - Specifica quali parti della API del motore Roblox possono essere utilizzate

Quando uno script tenta di eseguire un'azione che non è nell'insieme delle capacità per lo stato di esecuzione attuale, viene segnalato un errore. Gli errori di solito includono l'azione che viene tentata, il target di un'azione e la prima capacità che è mancante, per esempio:


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)

Controllo di esecuzione

Questo set include due capacità:

  • RunClientScript - LocalScript o Script con un valore di 0> Class.BaseScript.RunContext|RunContext0> con 3> Class.EnumerateRunContext 3> è consentito di eseguire sul client
  • RunServerScript - Script con un valore RunContext di 0> Enum.RunContext.Server|Server0> è consentito di eseguire sul Server

Se lo script è Enabled , ma la capacità corrispondente alla posizione in cui si tenta di avviare non è disponibile, un messaggio di avviso viene visualizzato nella finestra Output . Se uno script non dovrebbe essere eseguito in quel contesto, disabilitalo o eliminalo.

Nota che ModuleScripts non sono richiesti per avere queste capacità di esecuzione per essere richieste.

Quando uno script non riesce a iniziare a causa della mancanza della capacità di controllo dell'esecuzione, viene segnalato come avviso nell'Output, per esempio:


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

Controllo dell'Accesso all'istanza

Questo set include solo una singola capacità:

  • AccessOutsideWrite - Lo script è autorizzato a ottenere e ricevere istanze dall'esterno del container sandboxed

Quando la capacità non è disponibile, lo script può solo cercare istanze che sono all'interno del suo stesso container sandbox. Ad esempio, se lo script viene posizionato direttamente nel suo container sandbox, nil restituisce nil .

Inoltre, qualsiasi evento API Roblox che passa in un Instance invece passa in un nil per qualsiasi Instance al di fuori della sabbiera. Ad esempio, se il 2>Class.BasePart.Touched2> è segnalato da un tocco da un'istanza al di fu

Evita di impostare questa capacità; le garanzie di sandboxing sono più deboli quando gli script possono interagire con qualsiasi istanza in un'esperienza.

Accedi ai servizi

Anche senza AccessOutsideWrite , gli script nel container sabbistato possono ancora accedere a game , workspace e servizi. Questo accesso viene fornito in modo che gli script possano ancora chiamare metodi utili di questi globali, come 1> Class.DataModel.GetService1> , ma l'accesso ai loro istanze figli è ancora convalidato.

Istances interne passate

Se un'istanza viene passata attraverso una chiamata funzione che non passa attraverso le API Roblox, la riferimento viene preservata. Tuttavia, se un ModuleScript viene passato in questo modo, non può essere richiesto senza AccessOutsideWrite . Ciò è dovuto al fatto che il ritorno del ModuleScript è spesso mutabile e può essere modificato da uno script in

Controllo della funzionalità dello script

Questo insieme di capacità controlla alcuni aspetti generali degli script:

  • AssetRequirement - Lo script è autorizzato a chiamare require con un ID risorsa
  • LoadString - Lo script è autorizzato a chiamare loadstring
  • ScriptGlobals - Lo script ha shared e _G disponibili
  • CreaIstantze - Lo script può creare nuove istanze utilizzando Instance.new , Instance.fromExisting , o 0> Class.Instance:Clone0>

Tieni presente che le restrizioni della funzione predefinita sono ancora applicabili. Anche se LoadString è abilitato, l'esperienza deve ancora abilitarla in ServerScriptService , e non è ancora disponibile sul Server.

Per creare nuove istanze, oltre a Crea istanze , è necessaria un'ulteriore capacità API del motore fornire accesso a quella istanza.

Controllo API Motore

Questo ultimo gruppo di capacità controlla lo script di accesso a varie API del motore:

  • Base - Accesso a istanze semplici e blocchi di costruzione essenziali
  • Audio - Accedi alle istanze correlate alle API audio
  • DataStore - Accedi alle API del magazzino dati e alla memoria
  • Rete - Accesso alle API di rete HTTP
  • Fisica - Accedi alle istanze correlate alla fisica
  • UI - Accesso alle istanze correlate alle interfacce utente
  • CSG : accesso alle istanze e alle funzioni correlate alla geometria solida costruttiva (CSG (Geometria costruttiva dei solidi))
  • Chat : accesso alle istanze correlate alla chat in-experience
  • Animazione : accesso alle istanze correlate alle animazioni
  • Avatar : accesso alle istanze correlate agli avatar
  • Input : accesso alle istanze correlate all'input dell'utente
  • Ambiente : accesso alle istanze correlate al controllo di come viene visualizzato l'ambiente
  • RemoteEvent : accesso alle istanze per le operazioni di rete interna

Ci sono anche istanze disponibili senza nessuna capacità oltre a poter eseguire gli script. Questi includono i seguenti metodi HttpService :

Se una proprietà o un metodo dell'istanza viene accesso senza la capacità richiesta, viene segnalato un errore che descrive la capacità mancante.

Infine, le capacità non coprono ogni istanza nel motore Roblox oggi. Le istanze non elencate in questa sezione o la seguente non sono disponibili per l'interazione da un container sandbox e lanciare un errore dicendo che una Capacità non assegnata capacità non è disponibile per lo script corrente.

Un'ulteriore limitazione è che getfenv e setfenv funzioni non sono disponibili per gli script in un container sandbox.

L'accesso dello script alle istanze è limitato. Le istanze stesse possono ancora esistere e operare da sole all'interno di un container sandbox. Le luci brillano ancora, le interfacce utente sono ancora visibili e le impostazioni audio che sono già connesse suonano ancora.

Missioni API Motore

Ecco il elenco delle istanze e dei metodi (se diversi dalla capacità dell'istanza) per ciascuna capacità API del motore:

Interazioni tra container

Contenitori annidati

Quando uno container sabbistato è annidato all'interno di un altro, le istanze dello container interno sono accessibili all'esterno.

Le capacità del container interno sono limitate dalle capacità del container esterno. Ad esempio, se il container esterno ha le capacità di Base, Audio e CSG, mentre il container interno ha le capacità di 2> Base2> e 5> Rete5>, solo le capacità di 8> Base8> sono disponibili al momento dell'Tempo esecuzione.

Se non ci sono capacità in comune tra gli container interni e esterni, il risultato della capacità è vuoto.

Funzioni e eventi legabili

BindableEvent e BindableFunction forniscono il modo migliore per comunicare con il container o consentirgli di eseguire richiami con le capacità che non sono consentite direttamente.

Quando si verifica un evento o una funzione, le connessioni vengono eseguite nel contesto della funzione che le registra. Ciò significa che se l'evento o la funzione richiamata è registrato dal container sandboxed, viene chiamato con le capacità di quel container. Se il callback viene registrato dal codice esterno, quando gli script del container sandboxed vengono invocati, vengono eseguiti le tue funzioni con le capacità disponibili alle tue funzioni.

È importante notare che anche con la AccessOutsideWrite capacità, gli script in contenitori sabbiosi non possono invocare eventi o funzioni al di fuori dei loro contenitori se hanno un set di capacità più grande rispetto al contenitore stesso.

Requisiti del modulo

Inner ModuleScripts può essere richiesto dal container sabbistico come al solito. Tuttavia, se l'istanza target è all'esterno del container, l'ModuleScript può essere richiesto solo se il set di capacità che è disponibile per l'istanza è più piccolo o uguale alle capacità disponibili per il container.

Questa limitazione non si applica alle capacità RunClientScript e RunServerScript . Se il ModuleScript viene posizionato in un container con solo 1> RunClientScript1> ma è richiesto da uno script che ha la capacità 4> RunServerScript 4>, è permesso di riuscire e eseguire tali funzioni sul Server.

Funzioni chiamate direttamente

Se un ModuleScript in un container sabbistato è richiesto dall'esterno del container, alcune delle protezioni non sono disponibili. In particolare, la funzione target è in grado di accedere a tutte le istanze disponibili per il giocatore. Se il giocatore non è in un container sabbistato, l'appello agisce come se AccessOutsideWrite fosse disponibile per lui.

Altre restrizioni di capacità si applicano ancora. Se hai una capacità di Archiviazione dati accesso, ma il modulo target non lo fa, non è in grado di chiamare DataStore metodi. Tuttavia, se passi la tua funzione che lavora con DataStore, il target può eseguirlo durante quel chiamata. Se

Le istanze possono essere passate al modulo target o assegnate ai campi del modulo.

Se richiesto, è consigliato assegnare i membri della tabella utilizzando rawset per evitare l'esecuzione di metodi __index / __newindex metodi che potrebbero essere impostati sulla tabella.

La raccomandazione generale è di comunicare con BindableEvent e BindableFunction quando possibile.

Spostamento delle istanze

La maggior parte delle istanze non ha restrizioni sul movimento tra container. Le istanze di script, tuttavia, possono essere spostate solo in un container che ha lo stesso set di capacità o un sottoinsieme di queste capacità.

Questo significa che il container sabbioso con AccessOutsideWrite non può semplicemente re-genere uno script all'interno di sé all'esterno e ottenere più capacità.