Overriding Command Access (SourceMod)
This article explains how, without editing plugin source code, you can change the flags or permissions on any command, either globally, or for a specific group.
Introduction
Command access overrides are one of the most powerful aspects of the SourceMod administration system. They effectively let you:
- Change the access to any admin command without modifying plugin source code;
- Change the access to entire groups of commands without modifying source code;
- Create custom access levels;
- Allow or deny commands and groups of commands to an administrator group regardless of the command flags.
When you change the permissions to a SourceMod object, it is called an override. An override is an arbitrary string. If the override string matches a command name, then the command permissions will be inherited from that override.
This concept is important for two reasons:
- An override can change the permissions of a command.
- An override can be used as a custom access flag.
For example, a plugin might require access "g" to use the sm_map command. However, an override could explicitly allow/deny usage of this command to a given group, and/or it could change the default flag for sm_map to be "k" instead.
More interestingly, a plugin could require sm_map access in order to use a specific menu option. In this case, a user would have to be able to access sm_map, rather than have a hardcoded flag.
As a final example of the flexibility of this system, a plugin might say that users must be able to access plugin_crab_usage, which isn't a command at all. Instead, the plugin assumes a default access level internally, and users can opt to override it as they wish. This demonstrates that overrides are separate from commands, however, commands themselves inherit their permissions from overrides of the same name.
Changes to the override configuration are not immediate. You can reload overrides by issuing the "sm_reloadadmins" command.
Override Types
Overrides come in two flavors: command overrides and command group overrides. Command overrides are overrides that, if they have the same name as a command, that command will automatically inherit that override's permissions.
Similarly, a command group override is an override that which, if a command has the same group name as a command group override, that command will inherit the override's permissions.
Example 1: If a command override exists for sm_map, any admin command named sm_map will inherit those permissions.
Example 2: If a command group override exists for CSDM, any admin command labelled as a "CSDM" command will inherit those permissions.
Global Configuration
Access levels for overrides can be globally reconfigured via configs/admin_overrides.cfg. The file format is very simple:
Overrides { "[name1]" "[flags]" "@[group1]" "[flags]" /* ... */ }
Command groups are specified with an 'at' sign ('@') preceding the name. Example:
Overrides { "sm_map" "k" //Change "sm_map" to the "k" flag. "@CSDM" "m" //Change all CSDM commands to the "m" flag. "sm_chat" "" //Allow anyone to use "sm_chat" }
Note that given an arbitrary number of flags, the client must require access to all specified flags in the string, as opposed to just any one of them.
Group Configuration
Group overrides are given on an allow or deny basis. That is, rather than changing flags per-group, the override is simply whether it is allowed or denied to members of that group.
For more information, visit Adding Groups.
Warning: This template (and by extension, language format) should not be used, any pages using it should be switched to Template:Languages | |
View this page in: English Russian 简体中文(Simplified Chinese) |