This is an old revision of the document!

BeBot's Security Management System


BeBot's Security Management System aims to provide a common interface and structure for dealing with all things security. This document describes the use of the Security system for Module (and BeBot) Developers.

Access Levels

The core of BeBot security is the Access Level. An Access Level is a defined constant that cannot be changed. Access Levels are not security groups. The SUPERADMIN, ADMIN, and LEADER levels have the same names as BeBot's default security groups. The assist with differentiation, Access Levels are always referred to in uppercase letters and security groups are always lowercase.

BeBot has 8 Access Levels:

  1. OWNER (Bot Owner)
  3. ADMIN
  5. MEMBER (A member of the bot. Guild members in guildbot mode.)
  6. GUEST (Someone added to the guildbot's guestlist (Not used in raidbot mode by default))
  7. ANONYMOUS (Someone who is not a guest or member, but sends a tell to the bot.)
  8. BANNED (Someone who has been banned.)

All access is defined by these eight levels. Membership is additive, meaning if you are in a higher level you automatically are a member of lower levels too, with BANNED being the notable exception. So an ADMIN is a MEMBER, GUEST, LEADER and ANONYMOUS too.

User Levels, Org Ranks, and Security Groups

A user's Access Level is determined by their user level, security group membership, and their org rank. When BeBot is in guildbot mode, all members of the org are made members of the bot when the bot reads the org's roster. In addition to assigning this access level, the bot's superadmins are able to assign Access Levels to Org Ranks. For example, every General in your org can be given Leader access via the Security Access Level interface.

In addition to the security options provided by user levels and org ranks, the bot's superadmins are able to create custom security groups and add players to these groups. When a new security group is created, it is assigned the access level ANONYMOUS. Use the Security Access Level interface to raise and lower the access of a custom group.

Using the Security System in your modules

To make security easy for module developers, the check_access function provides all the security checks you will need. When assigning security to commands, you should always use one of the eight access levels, not security groups. This allows the bot user full flexibility with their configuration as org ranks and custom security groups must be assigned access levels.

For example, if your module's commands should only be used by bot leaders you would use the following code:

if ($this -> bot -> security -> check_access($playername, "LEADER"))
    return "You are a Leader or higher on <botname>!";
    return "You are not a Leader or higher on <botname>";

check_access returns TRUE if the player meets or exceeds the level you are checking. A player with an access or leader, admin, superadmin, or owner all meet or exceed the leader requirement.

  • security.1174729516.txt.gz
  • Last modified: 2020/09/12 01:30
  • (external edit)