Security Levels

I am currently working on a new feature for server administration - security levels.

Currently we have 3 levels of user on any given server - admins logged in via rcon, global mods and regular users. Admins can do everything that’s available to them, global mods can do a subset of this or nothing more than regular users, depending on a switch.

In the new system (security levels) this will be replaced with a series of arbitrarily-defined (i.e. create a new file to add a new one, rather than a fixed set) levels that map what users have access to what on your server.

You will be able to map levels either to the user roles (like guards, premium players or those currently logged into rcon) or specific usernames.

Each level will have 2 main features: a definition of the users or database roles that have that level, and a series of switches that determine what commands/features are available to that level.
The latter will mainly be made up of the rcon commands that they can use, but could also include additional features like the ability to join the server even after it has exceeded its limit (or alternatively be able to use ‘reserved slots’ if we go that way instead) or even pure aesthetic things like a star next to their name on the scoreboard.

You will be able to assign/deassign users to these levels in-game (via commands/menus) or by directly modifying the files.

I'm going to post examples of what the configuration files you'll use to define these levels will look like in the next post, so you can get a clearer idea of what's involved.
(Sorry folks I discussed JSON with, its just gonna have to be .cfg for the time being).

I'd very much like any feedback you might have on this concept. I've only just started coding it so there is plenty of room to adjust the design if you have good ideas :)

 

The following will be appended onto the file securitysetup.cfg:

# If 0, defers to hardcoded settings
levels_active = 1;

# Level file paths go here as a ;-delimited list - the order is important as users will be assigned the first level in this list that they match (i.e. if they are a superadmin they won’t be a normal, even though the match normal too). The default level (that users will be assigned if they do not match any of the other levels) is the last one in this list.
levels_files = Security/superadmin.cfg; Security/admin.cfg; Security/guard.cfg; Security/vip.cfg; Security/premium.cfg; Security/normal.cfg;

# When defining security levels, you may use the following variables:

# name is the display name of the security level

# users is a ;-delimited list of users this will apply to

# roles is a ;-delimited list of roles this will apply to.
# Available roles: premium (premium players), guard (KAG guards), rcon (people logged into rcon), admin (kag staff)

# commands is a ;-delimited list of rcon commands this level can use (in addition to those enabled on lower levels). Alternatively use the keyword ALL; to enable all rcon commands.
# Available commands: use /help in the game console for a list.

# features is a ;-delimited list of ‘extra features’ this level can use (in addition to those enabled on lower levels).
# Available extra features: join_full (join full server), join_reserved (join if reserved slots free), editor (use map editor), spectator (use spectator mode), kick_immunity (kick immunity), pingkick_immunity (ping kick immunity), ban_immunity (ban immunity), ingame_assignable (the level can be assigned to specific users in-game via commands/menu), assign_levels (this level can assign lower levels (that are assignable) to users of a lower level), view_rcon (can view posted rcon activity in console), post_rcon (rcon activity is posted to console of those that can view it)

 

Examples of security level definitions:

Security/superadmin.cfg:
name = Super Admin;
users = ServerOwner; Shadlington;
roles = rcon;
commands = ALL;
features = spectator; join_reserved; pingkick_immunity; join_full; kick_immunity; ban_immunity; editor; assign_levels;

Security/admin.cfg:
name = Admin;
users = ServerBuddy; Geti; AnotherServerBuddy;
roles =
commands = nextmap; restartmap; kick; ban; freeze; unfreeze;
features = spectator; join_reserved; pingkick_immunity; join_full; kick_immunity; ban_immunity; assign_levels; ingame_assignable

Security/guard.cfg:
name = Guard;
users =
roles = guard;
rcon = kick; ban; freeze; unfreeze;
features = spectator; join_reserved; pingkick_immunity; join_full;

Security/vip.cfg:
name = VIP;
users = somedude; anotherdude;
roles =
commands =
features = spectator; join_reserved; pingkick_immunity; star; ingame_assignable

Security/premium.cfg:
name = Premium;
users =
roles = premium;
commands =
features = spectator;

Security/normal.cfg:
name = Normal;
users =
roles =
commands =
features = spectator; ingame_assignable

 

How about renting a 2 slot server and giving everyone the power of joining a full server?

 

Renters that rent by slot will most likely lock down security level configurations, so they'd still have to use rcon password login.

Or we could add an extra switch in the dedi_autoconfig file for enabling join-when-full so that renters can just lock that file down.

 

Hrm. This isn't really about all the features that will be added that can be tied into security levels - I included most of them to illustrate what it could be used for.
Join full/reserved are probably the only ones I'll add in the first iteration.

I'm more concerned with feedback on the overall system. For example, is there any need for the API to return seclev info?

 

I like this. It means that dedicated, trusted players can be elevated in privilege without being admins. :D

 

Re: Colours. Possibly.
First iteration of seclevs won't have any 'bonus' features that didn't already exist, so things like custom colours would come later.