Skip to content

Configuring Users

Jump to bottom
Person8880 edited this page Mar 22, 2020 · 17 revisions

Overview

Shine's user system can be configured to either take users from a local file or from a remote URL. See the base config page for information on how to set up web users. Specifically, the settings "GetUsersFromWeb" and "UsersURL" control if and where to get web users.

If you have a user config file from DAK or the default NS2 users format, Shine will automatically convert it on first run. There's no need to remake the file if you are switching to Shine. Obviously you'll have to adjust the command names to match the ones in Shine.

If you are loading from the web, Shine will also recognise the NS2/DAK ServerAdmin.json file format and read it properly. It cannot read the format DAK uses to load from the web, only JSON data. It's advised to change it to the Shine format or at least change the command names to match Shine's, the converter will just replace sv_ with sh_.

Config

The default Shine user config file will look something like this:

{
    "Groups": {
      "SuperAdmin": {
        "IsBlacklist": true,
        "Immunity": 100,
        "Commands": [  ]
      },
      "Admin": {
        "IsBlacklist": false,
        "Immunity": 50,
        "Commands": [ "sh_kick", "sh_ban" ]
      },
      "Mod": {
        "IsBlacklist": false,
        "Immunity": 10,
        "Commands": [ "sh_kick" ]
      }
    },
    "Users": {
      "90000000000001": {
        "Group": "Mod",
        "Immunity": 2
      },
      "123456": {
         "Group": "Admin",
         "Immunity": 2
      },
    }
}

Note that the users listed are for the purpose of being an example only. I have no idea if anyone actually has either NS2ID, and you should obviously remove them from the list for your own config.

If you are getting this file locally, it should be called "UserConfig.json" and be under config://shine/UserConfig.json. If you are getting it remotely, the name is not important.

Group setup

The groups table is indexed by group names, so if you wish to make a new group called "Member", then you would add:

"Member": {
    "IsBlacklist": false,
    "Immunity": 5,
    "Commands": [ "sh_kick" ]
}

to the "Groups" table. Here this group has Immunity level 5, so it's below the default groups and can't target them. Also, as we've set IsBlacklist to false, this group can only run sh_kick.

Option Description
IsBlacklist If it is a blacklist, then it is a list of commands the group cannot run. Otherwise it is a list of commands they can run.
Commands Adding commands here will either allow or disallow the group from using them, depending on the IsBlacklist setting.
Immunity Sets the groups immunity level. Higher immunity levels are immune to lower levels.
CanAlwaysTarget If set to true, then the immunity level is ignored and members of this group can always be targeted by anyone.

Group inheritance

You can set up groups that inherit permissions from other groups. For example:

"SuperAdmin": {
  "IsBlacklist": false,
  "Immunity": 100,
  "Commands": [ "sh_unban", "sh_veto" ],
  "InheritsFrom": [ "Admin" ]
},
"Admin": {
  "IsBlacklist": false,
  "Immunity": 50,
  "Commands": [ "sh_ban" ],
  "InheritsFrom": [ "Mod" ]
},
"Mod": {
  "IsBlacklist": false,
  "Immunity": 10,
  "Commands": [ "sh_kick" ]
}

Here, the "SuperAdmin" group has access to sh_unban, sh_veto, sh_kick and sh_ban due to inheritance. As you can see, inheritance is recursive, so a group inherits not only the groups set in its "InheritsFrom" array, but all the groups those inherit from too, and so on.

You do not need to worry about cycles in inheritance, they will be dealt with properly.

Note that permissions inherit only from groups that share the same white/blacklist setting. So if the top group is a whitelist, then it will only inherit permissions from lower groups that are also whitelists, and vice-versa.

Advanced command access

Commands can be further customised with the following extra parameters:

Field Description
Allowed Either true to mark the command as always allowed, or a set of argument restrictions (see below).
Denied Set to true to explicitly block a command. This is useful in a whitelist group to block commands that are allowed by default.

Argument restrictions

You can setup groups to only have a restricted access to a command. For example, you might want to limit which plugins a group can load/unload, or you may want to give certain ranks the ability to only ban for a short time.

To set up a command with argument restrictions, create a group with a table something like this:

"LesserAdmin":
{
  "IsBlacklist": false,
  "Immunity": 20,
  "Commands": [
    {
      "Command": "sh_loadplugin",
      "Allowed": { "1": [ "tournamentmode", "mapvote", "pregame" ] }
    },
    {
      "Command": "sh_unloadplugin",
      "Allowed": { "1": "tournamentmode" }
    },
    {
      "Command": "sh_ban",
      "Allowed": {
        "2": { "Min": 1, "Max": 1440 }
      }
    },
    "sh_kick",
    "sh_gag"
  ]
}

In the group above, we've set access to a few commands with restrictions. Notice in the "Allowed" table, we use the argument's number as the key, and then the restriction information as its value. You can only restrict string and number arguments.

For string arguments, you can either set a single string to only allow that string as the argument (as in the "sh_unloadplugin" command in the example) or an array of strings to allow (as in the "sh_loadplugin" command in the example). Also, any string you set can contain * to set a wildcard match. For example, "speed *" would match any argument that starts with "speed ".

For number arguments, you can set a "Min" value, and/or a "Max" value, which will auto-clamp the argument the player gives into that range. In the example above, we restricted the duration argument (the 2nd argument of the command, hence the "2") of the "sh_ban" command to be between 1 and 1440 minutes.

For inheriting these restrictions, whitelist groups will take the first entry in the tree of groups for argument restriction. Blacklist groups will take the last entry in the tree. So if a whitelist group has full access for a command in the top group, then restricted access below, anyone in the top group has full access. If a blacklist group has full access in the top group, but restricted in the bottom, then anyone in the top group has the bottom group's restricted access.

Denying default commands

In a blacklist group, this is done by simply including the command in the list. However, in a whitelist group, you must mark the command as denied explicitly.

For example:

"UnstuckAbuse":
{
  "IsBlacklist": false,
  "Immunity": 0,
  "Commands": [
    {
      "Command": "sh_unstuck",
      "Denied": true
    }
  ]
}

This group cannot use sh_unstuck, but has all default access rights otherwise. This avoids having to use a blacklist group and account for every single command you do not want a user to have.

Using a default group

This group will be assigned to everyone who does not have a group set in the users list. You can use this group to globally assign badges, provide less strict access to commands and as a base group for other groups.

To add a default group, make a "DefaultGroup" entry in the user config file like this:

{
  "Groups": {
      ...
  },
  "Users": {
      ...
  },
  "DefaultGroup": {
    "IsBlacklist": false,
    "Immunity": 0,
    "Commands": [ ],
    "Badges": [ ]
  }
}

Make sure the default group entry is outside the groups table. Otherwise you will just be creating a group with the name "DefaultGroup" which is not the same thing. The reason the group must be defined in this way is to ensure there are no name clashes with the other named groups.

If you want a named group to inherit from the default group, add the "InheritFromDefault": true option to it. Note that the default group cannot inherit from other groups.

Also, be careful with the "IsBlacklist" setting in the default group. I highly advise leaving it as false. A blacklist is not suited for such a high risk, low permission group unless you want everyone to be an admin.

User setup

The users table can be indexed by:

  • NS2's in game ID (which is the Y number in the Steam3 ID).
  • The Steam2 format (STEAM_0:X:Y).
  • The Steam3 format ([U:1:Y]).

To add a user with NS2ID "123456" to the "Admin" group, you would add:

"123456": {
    "Group": "Admin"
}

to the "Users" table.

Option Description
Group Sets the user's group.
Immunity Overrides the groups immunity level for this user.

Special access commands

Some plugins specify commands that aren't actually commands but instead grant access or immunity to features. These should be added in the same way as normal commands to groups.

Command Description Default Access
sh_seelogechos Sets whether a group can see when others use commands (printed to their console). Denied
sh_view_system_notifications Sets whether a group can view system notifications (in the admin menu status tab). Denied
sh_ns2_voteaddcommanderbots Sets whether a user can use the "Add Commander Bots" NS2 vote. Allowed
sh_ns2_votechangemap Sets whether a user can use the "Change Map" NS2 vote. Allowed
sh_ns2_votingforceeventeams Sets whether a user can use the "Force Even Teams" NS2 vote. Allowed
sh_ns2_votekickplayer Sets whether a user can use the "Kick Player" vote. Allowed
sh_ns2_voterandomizerr Sets whether a user can use the "Randomise Ready Room" vote. Allowed
sh_ns2_voteresetgame Sets whether a user can use the "Reset Game" vote. Allowed
Clone this wiki locally