Minecraft - Setting up Permissions

Post Reply
User avatar
LHammonds
Site Admin
Site Admin
Posts: 920
Joined: Fri Jul 31, 2009 6:27 pm
Are you a filthy spam bot?: No
Location: Behind You
Contact:

Minecraft - Setting up Permissions

Post: # 381Post LHammonds »

**********************
Work In Progress
**********************


Overview

Once you get a Bukkit server started up, the 1st thing you should do is choose a permission plugin, install it and learn how to use it. Make sure you pick just one, you cannot have multiple permissions installed at the same time. Every plugin you install after this will make use of it.

There are various plugins to consider such as PermissionsEx, GroupManager, bPermissions, PermissionsBukkit etc.

I used to use bPermissions for my private LAN servers but switched to PermissionsEx (PEX) when I created a public server in order to make it easier to work with inherited permissions and donation systems and it was enjoying active development.

This tutorial will cover how to setup PermissionsEx (PEX) version 1.22.1 for a Bukkit 1.7.9 server.

You can find more detailed information about PEX on their wiki documentation site.

Initial Setup
  1. Make sure your Bukkit server is stopped
  2. Download the version of PermissionsEx that matches the version of Bukkit server you are running.
    For example, PermissionsEx 1.22.1 for CraftBukkit/Spigot 1.7.9
  3. Place the plugin in <server folder>\plugins\PermissionsEx.jar
  4. Start the server and let it finish loading. This will generate the initial configuration files.
  5. When the server is done loading, type "stop" on the console to shutdown the server.
Configuration File

Here is the default config.yml for version 1.22.1
multiserver: use-netevents: true permissions: debug: false allowOps: false user-add-groups-last: false log-players: false createUserRecords: false backend: file informplayers: changes: false backends: file: type: file file: permissions.yml updater: true alwaysUpdate: false
Permissions File

Here is the default permissions.yml for version 1.22.1:
groups: default: default: true options: permissions: - modifyworld.* schema-version: 1
NOTE: The "permissions:" should really be set under the group name and the "default: true" in this version should really be set under options as follows:
groups: default: permissions: - modifyworld.* options: default: true schema-version: 1
Permission Nodes

Developers of plugins can assign each permission node 1 of 3 default states: true, false, op

If you do not explicitly define the permission node, it will use the default setting as defined by the plugin author.

If the default is set to true, everyone gets that permission node. If false, everyone is denied access to that permission. If op, only operators has access to that permission.

When we assign permissions, we are overriding the default setting and making it work the way we want.

You can grant or negate permissions to users or groups and even use weighting on groups to override the same permission setting by a lower group.

Permission nodes in PermissionsEx, Group Manager and bPermissions look like this:
- plugin.feature1.node - plugin.feature2.node - plugin.feature3.node
Negative permission nodes (that take access away) in PermissionsEx and Group Manager look like this:
- -plugin.feature1.node - -plugin.feature2.node - -plugin.feature3.node
Negative permission nodes in bPermissions look like this:
- ^plugin.feature1.node - ^plugin.feature2.node - ^plugin.feature3.node
Groups

Groups are used to organize permission nodes.

Without groups, you would have to manage every player that comes on your server by assigning each permission node (nobody in their right mind would do this and it would be impossible to keep up with demand)

There are many different ways you can go about using groups. You could put all the permission nodes in 1 group so that everyone has the exact same access. Or you could make 2 groups where everyone has a certain set of permissions and another group can have a different set or a set in addition to the other.

With inheritance, you could setup groups that are never directly attached to any players but instead are attached to other groups that the player is assigned. This can also reduce the amount of permission nodes that are repeated, thus keeping the list smaller and easier to maintain.

Creating Groups
Syntax:
/pex group <GroupName> create
Deleting Groups
Syntax:
/pex group <GroupName> delete
Inheritance

A very powerful feature to PermissionsEx is inheritance. This means that one group can inherit (get the same permission nodes) another group...which can inherit any groups that group inherits (recursive inheritance)

This is particularly helpful when you have groups that build upon the rights of others. For example, admins can inherit all the permissions that moderators have and moderators can inherit all the permissions of a chat moderator. This means that admins have the same permissions that moderators AND chat moderators have because of recursive inheritance.

Permissions are assigned based on a pre-defined order and it is important to understand especially when you have conflicting nodes such as one group granting a permission with another group taking it away. Based on the order in which permission nodes are assigned, if a negative node has been assigned and later a positive node is granted, it will ignore the positive node so take care in the order of your assignments. Here is how PEX assigns nodes in order:
  1. Player settings are evaluated before group settings. If a players has a prefix of "Hello" and belongs to a group with a prefix set to "Goodbye," they will end up having the prefix of "Hello"
  2. Group settings that a player is directly associated with are evaluated before inherited groups. If a player is a member of the group "Crazy" and that group inherits another group called "Sane," the permission nodes in "Crazy" are assigned before the nodes in "Sane"
  3. Permission nodes are inherited in order of the permission tree. If you have a player that inherits from Donor and then Member, it will go through all the nodes in Donor and any inherited groups under Donor all the way down until it reaches the end of the inheritance chain. Then it looks at the Member group and goes through all the nodes in Member and any inherited groups under Member all the way down until it reaches the end of that inheritance chain.
  4. A group that inherits from another group will inherit everything from that group including any inherited groups (recursive inheritance).
Creating Group Inheritance
Syntax:
/pex group <GroupName> parents set <GroupName,GroupName,GroupName,etc.>
Examples:
/pex group Owner parents set Admin,pexowner,bukkitowner /pex group Admin parents set Moderator,pexadmin,bukkitadmin /pex group Moderator parents set ChatMod,bukkitmod /pex group Donor parents set Member /pex group Member parents set Guest /pex group Guest parents set bukkituser
Prefix / Suffix

A prefix and suffix are not part of the basic Minecraft server. Permission plugins add prefix and suffix support capability but it requires a chat plugin in order to use the prefix/suffix and see the result in-game.

A player can be associated to many groups which all have a prefix and/or suffix but only one of them will be assigned. You cannot combine the prefix of two or more groups. Just like the permission node inheritance rules, the same order applies here. If a player has a prefix or suffix directly to their account, it will override any group setting. If the player does not have a prefix/suffix directly set, they will get the prefix/suffix of their primary (1st) group if it has one. With clever planning, one could inherit a prefix from one group and a suffix from another group. On my servers, the prefix is always the rank of a player and every player has a rank of some kind. Staff member have additional groups and those groups have suffix settings so that any player attached to a staff position will have a suffix.

Syntax:
pex group <GroupName> set prefix "<Prefix>" pex group <GroupName> set suffix "<Suffix>" pex user <UserName> set prefix "<Prefix>" pex user <UserName> set suffix "<Suffix>"
Examples:
pex group Guest set prefix "[Guest] " pex group Guest set suffix " &a[Staff]"
Rank / Priority

The Rank / Priority is primarily for promotion ladders. It allows you to determine the order in which one travels up and down a ladder when there are multiple groups available in a ladder.

It also has a protection system such that if you can promote someone else, you can never promote them higher than your own level. For example, an admin could promote a chat moderator to full moderator and then promote them again to an admin but could not promote again to owner status.

Syntax:
/pex group <GroupName> set rank <Number>
Examples:
/pex group Guest set rank 999 /pex group Member set rank 800 /pex group Donor set rank 700 /pex group Guest set rank 999
Rank Ladders / Promotion and Demotion

When a new player joins the server, they fall into the default group we setup. In this case, the group is called "Guest" which is part of the ladder system called "Player"

If we promote a new player, they will go up the "Player" ladder to the "Member" group.

If you want to promote a staff member, they must 1st be added to an existing staff group. Once they are in that group, only then can they be promoted or demoted in that ladder system.

Syntax:
/pex promote <Username> <Ladder> /pex demote <Username> <Ladder>
Examples:
The following will promote the newly joined player from the Guest group to the Member group
/pex promote HammondsLegacy Player
The following will add this player to the ChatMod staff group in addition to his existing "Member" player group and then promote him to the Mod group.
/pex user HammondsLegacy group add ChatMod /pex promote HammondsLegacy Staff
The following will move this player down one group from Mod to ChatMod.
/pex demote HammondsLegacy Staff
MySQL

If you want to use a MySQL database, this is how you can convert back and forth between file and MySQL


If you have both "sql" and "file" backends correctly configured in config.yml, you can move data between them using the command: "/pex import <backend>"

YAML to MySQL
NOTE: This assumes you have all your permissions defined in the "permissions.yml" file and you do not need anything currently residing in the MySQL database...because the import will override whatever is there.
  1. Stop the server.
  2. Edit config.yml and set the backend to "sql" and setup the connection info correctly.
  3. Start the server.
  4. Make sure PEX successfully connected to the database.
  5. At the console, type "pex import file"
MySQL to YAML
NOTE: This assumes you have all your permissions defined in MySQL and you do not need anything currently residing in the "permissions.yml" file...because the import will override whatever is there.
  1. Stop the server.
  2. Edit config.yml and set the backend to "file" and make sure the MySQL connection info is correct.
  3. Start the server.
  4. Make sure PEX successfully initialized the file backend.
  5. At the console, type "pex import sql"
?
User avatar
LHammonds
Site Admin
Site Admin
Posts: 920
Joined: Fri Jul 31, 2009 6:27 pm
Are you a filthy spam bot?: No
Location: Behind You
Contact:

Re: Minecraft - Setting up Permissions

Post: # 382Post LHammonds »

Basic Permission Setup

We are going to setup 3 kinds of players and 4 staff positions:

Player Ranks
  1. Donor - This will be a group that players can upgrade to.
  2. Member - This will be a group that players can upgrade to.
  3. Guest - This is what new players will automatically get upon joining the server.
Staff Positions
  1. Owner - This will be a staff position that allows control over the server, plugins and their configuration.
  2. Admin - This will be a staff position that allows control over every aspect of the in-game world.
  3. Mod - This will be a staff position that allows control over other players in regards to kicking / banning.
  4. ChatMod - This will be a staff position that allows control over other players in regards to chatting.
All players will have their rank displayed to the left of their name using a prefix. All players are either Guest, Member or Donor (including staff). The staff positions will be noted in chat by a suffix being added to the name. This will only be visible if you have a chat plugin to make use of prefix/suffix options. This also means that staff will belong to two groups and most players will belong to just one in this example.

There will be 2 separate ladder systems for promotion/demotion. A player ladder will contain Guest, Member and Donor. A staff ladder will contain ChatMod, Mod, Admin and Owner.

At this point, we need to add server/bukkit and PEX permission nodes and move them into the appropriate groups.
groups: Owner: inheritance: - Admin - bukkitowner - pexowner options: rank: '100' suffix: ' [Owner]' rank-ladder: Staff Admin: inheritance: - bukkitadmin - Mod - pexadmin options: rank: '200' suffix: ' [Admin]' rank-ladder: Staff Mod: inheritance: - bukkitmod - ChatMod options: rank: '300' suffix: ' [Mod]' rank-ladder: Staff ChatMod: inheritance: - NothingYet options: rank: '400' suffix: ' [ChatMod]' rank-ladder: Staff Donor: inheritance: - Member options: rank: '700' prefix: '[Donor] ' rank-ladder: Player Member: inheritance: - Guest options: rank: '800' prefix: '[Member] ' rank-ladder: Player Guest: inheritance: - bukkituser options: default: true rank: '999' prefix: '[Guest] ' rank-ladder: Player bukkitowner: - bukkit.command.op - bukkit.command.op.give - bukkit.command.op.take - bukkit.command.plugins - bukkit.command.reload - bukkit.command.save - bukkit.command.save.disable - bukkit.command.save.enable - bukkit.command.save.perform - bukkit.command.seed - bukkit.command.stop - bukkit.command.timings - bukkit.command.version bukkitadmin: permissions: - bukkit.broadcast - bukkit.broadcast.admin - bukkit.command - bukkit.command.clear - bukkit.command.defaultgamemode - bukkit.command.difficulty - bukkit.command.gamemode - bukkit.command.gamerule - bukkit.command.give - bukkit.command.effect - bukkit.command.enchant - bukkit.command.help - bukkit.command.list - bukkit.command.me - bukkit.command.say - bukkit.command.spawnpoint - bukkit.command.teleport - bukkit.command.time - bukkit.command.toggledownfall - bukkit.command.unban - bukkit.command.unban.ip - bukkit.command.unban.player - bukkit.command.weather - bukkit.command.whitelist - bukkit.command.whitelist.add - bukkit.command.whitelist.disable - bukkit.command.whitelist.enable - bukkit.command.whitelist.list - bukkit.command.whitelist.reload - bukkit.command.whitelist.remove - bukkit.command.xp bukkitmod: permissions: - bukkit.command.ban - bukkit.command.ban.ip - bukkit.command.ban.player - bukkit.command.kick - bukkit.command.ban.list - bukkit.command.unban.player - bukkit.command.unban.ip - bukkit.command.teleport - bukkit.command.say bukkituser: permissions: - -bukkit.command.clear - -bukkit.command.me - -bukkit.command.plugins - -bukkit.command.version - bukkit.command.help - bukkit.broadcast.user - bukkit.command.tell - bukkit.command.kill pexowner: permissions: - permissions.debug - permissions.manage - permissions.manage.reload - permissions.manage.config - permissions.manage.backend - permissions.manage.dump - permissions.manage.membership.* - permissions.manage.groups.* pexadmin: permissions: - permissions.manage.worlds.* - permissions.manage.users.* - permissions.user.promote.* - permissions.user.demote.* users: a123456-1ab2-1abc-def2-12abcdefg345: options: name: HammondsLegacy group: - Donor - Owner b123456-1ab2-1abc-def2-12abcdefg345: options: name: PuppyBonjo group: - Member - Mod c123456-1ab2-1abc-def2-12abcdefg345: options: name: ArmyGuy007 group: - Donor d123456-1ab2-1abc-def2-12abcdefg345: options: name: may901 group: - Member e123456-1ab2-1abc-def2-12abcdefg345: options: name: ndog290 group: - Guest schema-version: 1
Post Reply