Scripts on Roblox have a thread identity which indicates what security access they have to the scripting API. Some class members in the scripting API can only be used by scripts that have the required permission.
A thread identity is an identity (an integer) given to a thread that indicates which permissions it has.
The identity of a thread can be found by using the printidentity function. This function will print the identity of the thread, prefixed by the last argument given to it if it is a string or a number, "(null)" otherwise, and a space. If no argument is given to it, it will prefix it by "Current identity is", followed by a space.
printidentity()would show Current identity is 2 in the output.
The identity of a thread will usually depend on where it comes from. For example, threads executed as plugins have an identity of 6, threads running code from the command bar or the "execute script" option have an identity of 5, and scripts and local scripts usually have an identity of 2.[note 1]
|1||User-initiated actions in Roblox Studio|
|2||BaseScript objects in any DataModel|
|3||BaseScript objects in any DataModel, in a place created by Roblox|
|4||BaseScript objects in any DataModel, if they were authored by Roblox|
|5|| Studio command bar, "Execute Script", |
|6||Studio plugins, COM API|
|7||Web service API|
|8||Receiving data via replication|
Each property, method, event or callback in the scripting API may require a permission. The existing permissions are PluginSecurity, RobloxPlaceSecurity, LocalUserSecurity, WritePlayerSecurity, RobloxScriptSecurity, RobloxSecurity, TestLocalUserSecurity, ScriptWriteRestricted: [NotAccessibleSecurity], and ScriptWriteRestricted: [PluginSecurity]. All threads have access to members that do not require a permission.
|None||Any identity can access this feature, including in-game scripts.|
|Plugin||Second-lowest access level, just above in-game script.|
|RobloxPlace||Places created by Roblox, where scripts are more trusted and preliminary features are allowed.|
|LocalUser||Non-game permission, usually for Roblox Studio.|
|WritePlayer||Permissions for changing player name, user ID etc.|
|RobloxScript||A script, such as a CoreScript, that is run inside a game.|
|Roblox||Highest level of permission.|
|TestLocalUser||In test builds, this is equivalent to no permission, but in regular builds it is equivalent to LocalUser.|
The table below shows which permissions are associated to each identity.
|1||Plugin, RobloxPlace, LocalUser|
|4||Plugin, RobloxPlace, LocalUser, RobloxScript|
|5||Plugin, RobloxPlace, LocalUser|
|6 (studio build)||Plugin|
|6 (non-studio build)||All permissions|
|8||RobloxPlace, WritePlayer, RobloxScript|
|Anything else||None, plus an assertion failure|
Threads with different identities can be run with different Lua virtual machines, so that user scripts are not mixed with scripts authored by Roblox. There are currently only two virtual machines, one for CoreScripts and other threads that have RobloxScript access and another for all the other threads. In studio builds, there is a third virtual machine used for studio plugins.
If the RobloxLocked property of an object is true, only scripts with the Plugin permission will be able to index signals and children of the object, set its properties or assign its callbacks, call yielding functions of the object, change the parent of the object's children, or create objects with the object as the parent using
Instance.new(class, parent). Furthermore, scripts that do not have this permission will not be able to call non-yielding functions of the object unless it is not a descendant of CoreGui. This property is used, among other things, for GUI objects created by CoreScripts.
- ↑ They can have an identify of 3 when executed in a game created by Roblox and an identify of 4 when they are whitelisted by Roblox.