Skip to main content

Configuring Security

The ins and outs of protecting your TV.

Understanding the Structure​

ProTV has a simple auth structure comprised of three levels:

  1. Standard User: This is your regular user who doesn't have any specific permissions.
  2. Authorized User: This level allows a limited amount of permissions. Can be viewed similar to a "moderator" or "manager" type of role.
  3. Super User: This level grants full control over the TV. Can be viewed as an "admin" type of role.

Super user permissions operate as follows:

  • Instance owner is always considered an implicit super user, unless Instance Owner Super User security tweak is disabled.
    • Group and Public instances do not have an instance owner as a User, so other auth methods are needed to handle those situations.
  • If Enable Domain Whitelist is enabled, super users can bypass the domain whitelist and post any link.
  • If super user override is enabled, super users can lock the TV to prevent both Standard and Authorized users from controlling it.
  • If First Master Super User is enabled, the first person in the instance will be treated as a super user for the lifetime of the instance.
    • Requires Allow First Master Control to be enabled as well.

Authorized user permissions operate as follows:

  • If Allow Master Control is enabled, the master is treated as an authorized user.
  • If Allow First Master Control is enabled, the first person to enter the instance retains authorized permissions for the lifetime of the instance.
  • Can lock the TV to prevent unauthorized users from controlling it.

More information about tweaking the security settings and tweaks can be found on the TVManager Guide

Custom Authentication​

ProTV includes an authentication plugin structure that you can build on top of to control who is considered to be authorized. To make your own auth plugin, simply inherit from the TVAuthPlugin class and implement the given methods as needed: _IsAuthorizedUser and _IsSuperUser, both of which receive a VRCPlayerApi object of the user being checked and return a boolean.

In your logic, make sure to call tv._Reauthorize() to signal to the TV that some authorization has been modified and that any plugins should check for those changes.

For an example, you can refer to the ArchiTech.ProTV/Runtime/Auth/TVManagedWhitelist.cs for a simple implementation.

Caveats and Soft-Lock Risks​

When dealing with the security settings of locking down the TV, there are certain scenarios which can cause an accidental soft-lock, meaning that the TV becomes effectively inoperable due to the fact that no-one meets the security requirements of the TV's settings. Here are the most common soft-lock scenarios that can occur:

  • If there is no Authentication Plugin connected, Allow Master Control is disabled and Locked By Default is on, all GROUP or PUBLIC instances will be inoperable because in those instance types, the instance owner is not available. Instance Owner is only present for Friends or Invite type instances.
    If this scenario is detected in editor, a critical warning will be displayed in the inspector of the offending TVManager.
  • In addition to the previous, if you DO have an authentication plugin connected, you must have some users that are recognized as authorized or super, or else it will again become inoperable due to the lack of users who are considered authorized.