• 欢迎来到Minecraft插件百科!
  • 对百科编辑一脸懵逼?帮助:快速入门带您快速熟悉百科编辑!
  • 因近日遭受攻击,百科现已限制编辑,有意编辑请加入插件百科企鹅群:223812289

PermissionsEX

来自Minecraft插件百科
Zhw讨论 | 贡献2015年2月1日 (日) 11:06的版本 Important File Back-end Notes
跳转至: 导航搜索
Icon-info.png
本页面已存在其他语言的内容,请协助翻译为本地化的中文。
  • 点击此处开始翻译。
  • 如本模板出现在原文存档页面,请注意更新主页面后,仍需要去除此处该模板。
  • 如当前页面已经没有需要翻译的内容,请删去待翻译模板。
  • 有标题的大篇幅文章,如果短时间内无法全部翻译,请先把所有的标题翻译出来,以便之后的贡献者选择与翻译章节内容。
PermissonEX(PEX)
外文名PermissonEX(PEX)
插件类型Spigot / CraftBukkit
最新版本v1.23.1
兼容服务端1.8.1
前置插件
源地址http://dev.bukkit.org/bukkit-plugins/PermissionsEX

概述

介绍

PermissionsEx (PEX) 是一个新的权限(组), 基于权限组和它的所有功能. 但是PEX插件能做到更多! 它提供了各式各样有力的后台和游戏内管理方式, 很好的限制了一些玩家对于服务器的修改.

现有特性

Support for UUIDs as of version 1.21 Several backend support. Currently bundled backends is File (YAML) and SQL (MySQL, SQLite). Also it's possible to add your own. YAML backend, with new, fully rethinked, config schema. Now all user, groups and their permissions are stored in one file - permission.yml. File name can also be adjusted. SQL backend, most delicious. Currently MySQL and SQLite supported, but other DB (like Postgre) are possible too. PEX deploys the DB scheme (tables and initial data) automatically. This means, that you only need to provide data on how to connect to the db, everything else PEX will handle by itself. Flexible architecture and API - you can change a lot programmatically. Rich chat/console command interface. You can do almost everything ingame. Command list below. Modifyworld - Permission-based restrictions mechanism (we call it "modifyworld"), which provides the possibility to control players abilities, such as destroying/placing blocks, riding carts/boats or even getting spotted by mobs and much more. Available from its project page Multigroup inheritance. User, as well as Group, can be member of several groups. And inherit their permissions, options and prefix/suffix. Permissions based upon Regular Expressions. This mean you can use regular expressions. Example: modifyworld.blocks.(destroy|place).(3|12) - this permission allow place or destroy only sand (12) or dirt (3) blocks. There is still limitation on dot usage in your regexps - dots are escaped by default. Raw regex flag is also available and explained on the wiki. Multiworld permissions. Just don't specify world and permission would work in any world. Multiworld inheritance. You can inherit different groups in different worlds. Perfomance friendly. Low-level caching helps a lot when you have 100+ online users Promotional/Demotional system. You can assign ranks to groups and promote/demote users to higher/lower ranked group. NEW: new you can make serveral ranking ladders. World-inheritance - permissions/option of one world can be inherited by another world. Timed Permissions - you can give user permission only for some amount of time. As of version 1.21.1, PermissionsEx automatically updates to keep you up to date with the latest bugfixes and new features. The automatic update functionality will only perform updates between minor releases (for example only 1.21.1->1.21.2, not 1.21.3->1.22). To disable it, set the updater option to false in plugins/PermissionsEx/config.yml. Bukkit Permissions (SuperPerms) compatible. To disable error reporting, create a file called `report-disable` in the plugins/PermissionsEx folder. Note that enabling this option means you WILL NOT get any support for errors because the information published (permissions file, configuration, and versions) is essential to resolving issues.

进阶权限管理

权限的继承

很多服务器配置了多个权限组, 添加权限要各组分别添加. 权限继承允许服务器管理最大限度地减少每一组重复的节点数量.

这里假定您已经完成了基本教程,如还没有,请看基础权限知识,不然的话不能保证您能明白这里的每一步.

实际上,使用了基本教程中的案例,你会发现Member, VIP 和Moderator组都有共同的节点 , modifyworld.* .这里不需要使用继承.

Permissions Inheritance Rules

When dealing with inheritance, PEX follows a few rules:

Player specific settings (prefix, suffix, permission nodes, etc) are evaluated before group level settings Settings that are part of the group the player is a member of are evaluated before inherited settings Permission nodes are evaluated in order of the inheritance tree (see The Inheritance Tree for details) A group set to inherit from another group will inherit everything (this includes other inheritance directives!) from the source group, not just permissions. For example, if you have group B inheriting from group A, and group A is set to inherit from group B, PEX will follow the inheritance chain on group A, which is set to inherit from B, which inherits from A, and so on. Watch for this, it will cause a loop that will crash PEX.

Converting Existing Groups To Use Inheritance

Converting an existing group to use inheritance is easy with the pex group parents set command.

Convert the VIP and Moderator groups

pex group VIP parents set Member
pex group Moderator parents set VIP
Remove the redundant nodes
pex group VIP remove modifyworld.*
pex group Moderator remove modifyworld.*

At this point, the VIP and Moderator groups still have the same access as before as the VIP group inherits the modifyworld.* node from the Member group while adding the -modifyworld.mobtarget.monster.creeper node, and the Moderator group inherits it's nodes from the VIP group (including the nodes it inherited from the Member group) while adding the -modifyworld.mobtarget.* node.

The relevant portion of the permissions file now looks like this:

   Member:
       prefix: '&0(&8M&7ember&0)&7 '
       permissions:
       - modifyworld.*
       options:
           rank: '900'
   VIP:
       prefix: '&0(&eVIP&0)&7 '
       inheritance:
       - Member
       permissions:
       - -modifyworld.mobtarget.monster.creeper
       options:
           rank: '800'
   Moderator:
       prefix: '&0(&1Moderator&0)&7 '
       inheritance:
       - VIP
       permissions:
       - -modifyworld.mobtarget.*
       options:
           rank: '100'

It's not a large reduction with this example, but if a server has multiple groups with a dozen or more nodes in common with the groups, the file size savings can be considerable.

This inheritance can also be applied at a world level for servers with multiple worlds. See the Multiworld inheritance section page for more.

The Inheritance Tree

(Thanks goes to aviator14 for use of these nodes)

Due to the way PEX deals with file backends, it may help to view inheritance as a tree. For example, we have the following permission nodes:

 Guest:
   prefix: '&7'
   default: true
   permissions: []
 Player:
   prefix: '&f'
   default: false
   permissions:
   - generic.user.permissions
   - -multiverse.access.world_creative
   - -multiverse.portal.access.end
   - multiverse.access.*
   - multiverse.core.coord
   - multiverse.core.info
   - multiverse.core.list.who
   - multiverse.portal.access.*
   inheritance:
   - Guest
 Donator:
   prefix: '&5'
   permissions:
   - generic.donor.permissions
   - multiverse.access.world_creative
   inheritance:
   - Player
 Supporter:
   prefix: '&6'
   permissions:
   - more.generic.donor.permissons
   - multiverse.portal.access.end
   inheritance:
   - Donator
 Moderator:
   prefix: '&d'
   permissions:
   - generic.moderator.permissions
   inheritance:
   - Player
 ModD:
   prefix: '&d'
   permissions: []
   inheritance:
   - Moderator
   - Donator
 ModS:
   prefix: '&d'
   permissions: []
   inheritance:
   - Moderator
   - Supporter

The original forum post these nodes came from was asking why the ModD group was not getting the multiverse.portal.access.end node it was inheriting from the Donator group. Well, the reason for this is because of the way PEX evaluates nodes in a file backend and the inheritance tree.

An abbreviated version of the tree for the ModD group is this:

ModD permissions (none) Moderator (generic.moderator.permissions) which inherits from Player Player (which has -multiverse.access.world_creative among others) and inherits from Guest Guest (no permissions) Donator (generic.donor.permissions, multiverse portal access node) which inherits from Player Player (which has -multiverse.access.world_creative among others) and inherits from Guest Guest (no permissions) In this case, the issue was due to the Moderator tree being evaluated first, which finds the negation node for multiverse and stops looking. If the Donator tree was listed first (which was the suggested fix), PEX would follow that inheritance tree first, which has the multiverse permissions, and allow access to that node.

Regular Expressions (regex)

Regular Expressions, also known as regex or regexp, is a way to 'match' strings of text, such as particular characters, words, or patterns of characters. PEX supports a subset of regex in it's permission node checks.

PEX supports open and closed parentheses ( ) for grouping, curly braces { } for pattern matching, a pipe | for "or", and a dash - for through (as in numbers 1 through 5).

WARNING: If you have any nodes that use these characters then you MUST either put the line in quotes or escape with a backslash the character. If you do not, PEX may mistake the character as an attempt to use a regex, causing a Java error and rendering your permissions useless!

To use it, place the conditions/keywords and/or id numbers in a group, separated by a pipe or a dash if wanting to cover multiple numbers in a sequence.

If this is confusing, worry not. There is a reason why several technical book publishers sell books dedicated to regular expressions. Fortunately, for the purposes of PEX and permission nodes, it's much simpler to deal with, especially with examples of it in action.

Assume that you have a group that you don't want opening the following:

Dispensers ('dispenser', or 23)
Chests ('chest', or 54)
Furnaces ('furnace', or 61 unlit and 'burning_furnance', or 62 lit)
Jukeboxes ('jukebox', or 84)
Remember to check your use-material-names node setting.

You could have a set of nodes like this:

- -modifyworld.blocks.interact.dispenser
- -modifyworld.blocks.interact.chest
- -modifyworld.blocks.interact.furnace
- -modifyworld.blocks.interact.burning_furnace
- -modifyworld.blocks.interact.jukebox

However, this is unnecessary. Using the regex support in PEX, you can combine the nodes into a single line: - -modifyworld.blocks.interact.(dispenser|chest|burning_furnace|furnace|jukebox) - -modifyworld.blocks.interact.(23|54|61|62|84) (for use-material-names: false)

If you wanted to keep a group from destroying stone (1), grass (2), dirt (3), and cobblestone (4), you can use modifyworld.blocks.destroy.(1-4)

You can also use 'or' on other parts of the node.

Keeping with the previous example, adding the ability to place the blocks looks like modifyworld.blocks.(destroy|place).(1-4) Adding sand (12) to this example, you could use modifyworld.blocks.(destroy|place).(1-4|12)

Adding this to a group, such as the default group, is as simple as using the pex group <group> add <node> command.

pex group default add modifyworld.blocks.(destroy|place).(1-4|12) Any extra nodes can be removed with the pex group <group> remove <node> command. See Commands for more on the add/remove commands.

For advanced users, users can place a $ character directly in front of the node (after any other flag characters) to prevent PEX from performing regex escaping of . and *, so that they behave as normal regex characters rather than their function as delimiters in permissions nodes (escaped by default for backwards compatibility and user sanity)

As you can see, the ability to use regex in permissions can save a lot of typing.

File Back-end Example

In the interest of completeness, this is the full permissions file after the inheritance and regex commands listed above. This example assume use-material-names: false in your plugins/Modifyworld/config.yml file.

groups:

   default:
       default: true
       options:
           rank: '1000'
       permissions:
       - modifyworld.chat
       - modifyworld.blocks.(destroy|place).(1-4|12)
   Member:
       prefix: '&0(&8M&7ember&0)&7 '
       permissions:
       - modifyworld.*
       options:
           rank: '900'
   VIP:
       prefix: '&0(&eVIP&0)&7 '
       inheritance:
       - Member
       permissions:
       - -modifyworld.mobtarget.monster.creeper
       options:
           rank: '800'
   Moderator:
       prefix: '&0(&1Moderator&0)&7 '
       inheritance:
       - VIP
       permissions:
       - -modifyworld.mobtarget.*
       options:
           rank: '100'
   Admins:
       prefix: '&0(&4Admins&0)&7 '
       permissions:
       - -modifyworld.mobtarget.*
       - modifyworld.*
       - permissions.*
       options:
           rank: '1'

users:

   AnotherPlayer:
       group:
       - default
   YourPlayerName:
       group:
       - Admins

===Multiworld===Multiworld

Having several maps (or worlds) on a server is a common way to offer more than one game play experience. However, not all commands are suitable for all worlds. You wouldn't want a hardcore survival world to have access to the give command, but it may be perfectly fine, if not required, in a world intended for free building. Fortunately, limiting a permission node to a specific world is easy with PEX by specifying the world when adding the permission node.

Assume the following server setup:

A survival world with Nether and End worlds (named survival, survival_nether, and survival_the_end respectively)
A free build world (named freebuild)
A group (pvp) that has the ability to build in the survival world only (modifyworld.*)
A group (build) that has the ability to build in the survival and free build world (modifyworld.*)

See Modifyworld page for details on block placement permission nodes.

The commands to set this up are:

/pex group pvp add modifyworld.* survival (add build permissions to the survival world for the pvp group)
/pex group build add modifyworld.* freebuild (add build permissions to the freebuild world for the build group)
/pex group build parents set pvp (Set the build group to inherit the permission to build in the survival world)

Keep in mind that if you edit/add the multiworld lines into the permissions file by hand, make sure the name you use matches the one used in the bukkit configs and what is on the server, capitalization matters here!

The resulting permissions will look like this in the file back-end:

groups:

   pvp:
       permissions:
       worlds:
           survival:
               permissions:
               - modifyworld.*
   build:
       inheritance:
       - pvp
       permissions:
       worlds:
           freebuild:
               permissions:
               - modifyworld.*

Multiworld inheritance

You may have noticed the flaw in this setup, which is neither group had permission to build in the Nether and End worlds. This can be corrected in two ways:

Add the modifyworld.* node to each world individually Set up world-level inheritance using /pex world <world> inherit <parentWorlds> /pex world pvp_nether inherit pvp /pex world pvp_the_end inherit pvp These commands look like the following in the file back-end:

worlds:

   pvp_nether:
       inheritance:
       - pvp
   pvp_the_end:
       inheritance:
       - pvp

Backends

原帖是这么说的 PermissionsEx provides several backends to store permissions data. This page (will explain) explains them all. (PEX插件提供了一些用于保存权限数据的后台,这个页面会解释所有) 但其实这个页面只有这一句话(或许是服务器问题) 所以请等待更新。

基础的权限设定

权限节点的基本添加和否定

PEX插件有一个普遍原则,就是权限运行命令是不允许的,除非这个权限节点是具体列出的(非白即黑原则). 对于那些可以被默认(default)操作的事件和命令, PEX插件可以拒绝访问那些被否定的节点.

使用一个可以拒绝访问节点就像用 pex group <group> add <node>(最基本的权限给予命令) 命令那样简单. 使用同样的命令,只在权限节点前加一个负号(-)即可.

举个例子 /give 和 /plugins 命令是水桶客户端的一部分(基本命令)

/give 命令有一个权限节点 command.give 这个命令一般限制在ops.txt列出的人使用(管理员命令)
/plugins 命令也有个权限节点 command.plugins 它可以被服务器中任何人使用。

我们可以试试对于某个权限组增加和否定这两个节点:

如果允许某个权限组使用/give, 就可以输入命令 pex group 组别名 add bukkit.command.give
不允许某个权限组使用 /plugins, 这时候的命令就为 pex group 组别名 add -bukkit.command.plugins

重要的关于*的信息

PEX插件允许使用XXX*来给予XXX下的所有的分权限节点,但是呢,在使用这个前,你必须要明白它怎么工作以及会造成什么效果。一开始浏览的时候,这看上去很简单,给一个权限组“*”使它可以访问所有的权限节点,但是这也可能会导致你给了你不想要给这个权限组的权限。例如,在插件VanishNoPacket(简称VNP)中,它提供了一个权限vanish.silentjoin,使得所有的用户在登入时都不会显示加入公告,这是大多数服务器主人都不想要的效果。实际上这也可以用否定节点来简单解决(否定节点优先),任何给默认组使用的权限节点都能被否定以“关闭功能”

重要的后台文件

如果你要在后台修改编辑权限的话,请阅读并遵守以下规则: 权限必须以一个空格或者负号开始 - modifyworld.chat 和 - -modifyworld.mobtarget.*是在后台文件中有效的(格式正确)。 modifyworld.chat 和 -modifyworld.mobtarget.* 在后台文件中无效(格式不正确,无空格或负号)。 所有在YAML文件中的格式规则在PEX插件基本文件中必须被遵守,错误的文件会使得PEX插件无法启动,然后把log文件塞满错误信息。 PEX插件用自上而下的方式来检查用户和组别的权限节点,就像网络防火墙一样,如果它找到了一个与它想找的匹配的节点,它就会停止寻找,这就意味着在现实中,如果一个权限给了主要组别和它所有的子组别,它在看到允许的权限后就会停止寻找而忽略否定节点。 我们举个错误的例子

default:

 options:
   default: true
 permissions:
 - modifyworld.*
 - -modifyworld.blocks.interact.23

用这样的权限节点文件,如果一个玩家想要打开一个发射器(ID 23),它第一个会匹配到modifyworld.*节点然后停止,以至于允许玩家打开!(实际上第二个权限节点是不允许这样的事情发生的。)

不过,如果把这两行互换,-modifyworld.blocks.interact.23在modifyworld.*之前,玩家会被拒绝访问发射器(插件先检测到-modifyworld.blocks.interact.23节点)如果一个玩家想要打开一个熔炉(ID 61)插件就会检测到modifyworld.*节点,然后认为是modifyworld.blocks.interact.61节点,使得玩家可以打开。

Tutorial Goals

Setup a basic and simple permissions infrastructure Create additional groups: Member, VIP, Mod, Admin

"Default" is able to chat but cannot modify anything and doesn't have a prefix
"Member" is a trusted player group. Those players can modify the world and have a colored prefix ("&0(&8M&7ember&0)&7 ")
"VIP" is able to modify the world and is not targeted by creepers. Those players will have a prefix "&0(&eVIP&0)&7 ".
A "Mod" (Moderator) is able to modify the world and is not targeted by any mobs.
An "Admin" (Administrator) is a superuser and has access to all PEX commands. They get a fancy prefix like "&0(&4Admin&0)&7 ".

OPTIONAL: Remove modifyworld.* permission from "Default" group OPTIONAL: Add modifyworld.chat permission to "Default" group Testing your environment

Preparations

Install and configure (Plugin Configuration) PermissionsEx. OPTIONAL: Activate ModifyWorld. See Modifyworld, Configuration for more. Start your server. Open up the Commands section in a separate web browser window Open the YAML Notes in the PEX Basics page in a separate web browser window

Setup a basic and simple permissions infrastructure (top)

These commands must be entered at the console

Create the "Admin" group with pex group Admin create

Add the permissions.* permission to this group with pex group Admin add permissions.*. Add yourself to this group with pex user YourPlayerName group set Admin, replacing YourPlayerName with your in-game name. OPTIONAL: Give yourself permissions to access all PEX commands regardless of the group you are in with pex user YourPlayerName add permissions.*

If you do not have access to the console

Create a permissions.yml file as follows and upload it to the PermissionsEx directory, making sure that the formatting is exact and correct! See the YAML Notes in the PEX Basics page page for details.

groups: Default:

 options:
   default: true
 permissions:
modifyworld.* Admin: options: prefix: '&0(&4Admin&0)&7 ' permissions:
permissions.* users: YourPlayerName: group:
Admin permissions:
permissions.*

Now connect to your server to create groups Member, VIP and Mod.

Create additional groups: Member, VIP, Mod

Create the Member group with /pex group Member create
Create the VIP group with /pex group VIP create
Create the Mod group with /pex group Mod create

Next, we will assign ranks to those groups and set the Rank order to Member -> VIP -> Mod -> Admin. See Ranks (Promotion and Demotion) for more.

Set rank order

/pex group default set rank 1000
/pex group Member set rank 900
/pex group VIP set rank 800
/pex group Mod set rank 100
/pex group Admin set rank 1

Rank 100 is now the highest promotion status.

Be aware that the promote and demote commands have restrictions in-game (but not in the console). In-game, you can not:

promote a player who is below your rank up to your rank (Mod to Admin, using the previous example) demote a player that is above your rank down to your rank (Admin to Mod, using the previous example) promote/demote a player who is at your rank (you can't promote/demote a Mod at all if you are a Mod; you can't promote/demote an Admin at all if you are an Admin) If you are (for example) an Admin group member and want to assign another player to the Admin group while you are in-game, you must set it directly by using the command /pex user PlayerName group set Admin.

The promote and demote commands will work on any player of any rank from the console, without restrictions.

Add fancy prefixes!

/pex group Member prefix "&0(&8M&7ember&0)&7 "
/pex group VIP prefix "&0(&eVIP&0)&7 "
/pex group Mod prefix "&0(&1Mod&0)&7 "
/pex group Admin prefix "&0(&4Admin&0)&7 "

Be aware that there is a blank space after each prefix. This prevents the prefix of your group from being smashed up against the username in chat. (And, similarly, a blank space comes before any suffix you would use for the same reason - so the username is not smashed up against the suffix. To assign suffixes, simply replace the word prefix with the word suffix when using the commands above and your own custom suffixes.)

Add permissions to each group

NOTE: If you have not enabled ModifyWorld, the modifyworld.* lines can be skipped.

OPTIONAL: /pex group default remove modifyworld.* OPTIONAL: /pex group default add modifyworld.chat (Only needed if modifyworld.* has been removed)

/pex group Member add modifyworld.*
/pex group VIP add modifyworld.*
/pex group VIP add -modifyworld.mobtarget.monster.creeper
/pex group Mod add modifyworld.*
/pex group Mod add -modifyworld.mobtarget.*
/pex group Admin add permissions.*
/pex group Admin add modifyworld.*
/pex group Admin add -modifyworld.mobtarget.*

Now it's time to test your setup

Testing your environment(top)

For each section, change your group to the specified group with /pex user YourPlayerName group set GroupName

Default

Verify that you can chat
Verify that the right prefix is shown in the chat window
Verify that you can modify the world by breaking a block outside of the spawn area

NOTE: If modifyworld was enabled and the modifyworld.* node was removed, you should not be able to If you have enabled modifyworld and the modifyworld.* node was removed, find and run into a creeper! (Don't be afraid, it will not be able to target you, nor can you harm it) Member

Verify that you can chat
Verify that the right prefix is shown in chat window
Verify that you can modify the world by breaking a block outside of the spawn area

VIP

Verify that you can chat
Verify that the right prefix is shown in chat window
Verify that you can modify the world by breaking a block outside of the spawn area

If you have enabled modifyworld and the modifyworld.* node was removed, find and run into a creeper! (Don't be afraid, it will not be able to target you, but should be able to hurt it) Admin

Verify that you can chat
Verify that the right prefix is shown in chat window
Verify that you can modify the world by breaking a block outside of the spawn area (if you have put your player name in the ops.txt and set allowOps to true in the PEX Configuration File, you will be able to break blocks in the spawn area).
Verify that you have access to all PEX commands (Run /pex reload as a test, it should respond with "Permissions Reloaded")
Verify that you are not targeted by any mobs

For the next step, you will be creating a "virtual" user. Alternately, have a friend join the server and use them as the test subject (It's for Science!)

Test the ranks (top)

/pex user AnotherPlayer group set default

Verify that the promotion/demotion queue is working by using /pex promote AnotherPlayer. You should see "User AnotherPlayer promoted to NextGroup" Keep doing this until you see "Promotion error: User is not promotable". Running /pex user AnotherPlayer should show the following: playername are member of:

Mod (rank 100 @ default)

playername's permissions:

-modifyworld.mobtarget.* (from Mod)

modifyworld.* (from Mod) playername's options:

Demotion is the same as promotion, just change the word promote with demote

If the player was virtual, remove them afterwards with /pex user AnotherPlayer delete if you want If the player was real, check every group to verify that it is working as it should (see the Goals list)

File Backend Example (top)

For reference, following the example above will result in the following permissions.yml file. If you use this as an example for making your permissions file, make note of the indenting and capitalization of the various header names:

groups:

 default:
   options:
     rank: '1000'
     default: true
   permissions:
   - modifyworld.chat
 Member:
   permissions:
   - modifyworld.*
   options:
     rank: '900'
     prefix: '&0(&8M&7ember&0)&7 '
 VIP:
   permissions:
   - -modifyworld.mobtarget.monster.creeper
   - modifyworld.*
   options:
     rank: '800'
     prefix: '&0(&eVIP&0)&7 '
 Mod:
   permissions:
   - -modifyworld.mobtarget.*
   - modifyworld.*
   options:
     rank: '100'
     prefix: '&0(&1Mod&0)&7 '
 Admin:
   permissions:
   - -modifyworld.mobtarget.*
   - modifyworld.*
   - permissions.*
   options:
     rank: '1'
     prefix: '&0(&4Admin&0)&7 '

users:

 AnotherPlayer:
   group:
   - default
 YourPlayerName:
   group:
   - Admin

And this is how the file looks to PEX after being parsed. Use an on-line YAML checker to verify your permissions file looks similar. If it does not, PEX will not work as expected and may throw all kinds of errors!

{

 "users": {
   "AnotherPlayer": {
     "group": [
       "default"
     ]
   }, 
   "YourPlayerName": {
     "group": [
       "Admin"
     ]
   }
 }, 
 "groups": {
   "default": {
     "options": {
       "default": true, 
       "rank": "1000"
     }, 
     "permissions": [
       "modifyworld.chat"
     ]
   }, 
   "Member": {
     "options": {
       "prefix": "&0(&8M&7ember&0)&7 ", 
       "rank": "900"
     }, 
     "permissions": [
       "modifyworld.*"
     ]
   }, 
   "VIP": {
     "options": {
       "prefix": "&0(&eVIP&0)&7 ", 
       "rank": "800"
     }, 
     "permissions": [
       "-modifyworld.mobtarget.monster.creeper", 
       "modifyworld.*"
     ]
   }, 
   "Mod": {
     "options": {
       "prefix": "&0(&1Mod&0)&7 ", 
       "rank": "100"
     }, 
     "permissions": [
       "-modifyworld.mobtarget.*", 
       "modifyworld.*"
     ]
   }, 
   "Admin": {
     "options": {
       "prefix": "&0(&4Admin&0)&7 ", 
       "rank": "1"
     }, 
     "permissions": [
       "-modifyworld.mobtarget.*", 
       "modifyworld.*", 
       "permissions.*"
     ]
   }
 }

}

Chat Manager

Commands

Utility commands

由于原帖格式原因,搬运过来后作如下解释 格式为: 命令(省略斜杠) 权限 作用

pex	permissions.manage	Display help
pex toggle debug	permissions.debug	Enable/disable debug mode (Caution: This will produce a lot of entries in your server.log file. Use this only  for debugging!)
pex user <user> toggle debug	permissions.manage.<user>	Enable/disable debug mode on a specific user (Caution: This only enables logging for a single user, but can still generate lots of entries in your server.log file)
pex user <user> check <permission>	permissions.manage.<user>	Checks 1 specific permission against 1 specific user
pex reload	permissions.manage.reload	Reload the pex environment
pex config <node> [value]	permissions.manage.config	Print <node> value from plugin configuration. Specify [value] to set a new value
pex backend	permissions.manage.backend	Print the currently used backend
pex backend <backend>	permissions.manage.backend	Change the permissions backend on-the-fly (Use with caution!) Note that this will only change the backend on-the-fly, it will not save the change in the config file, nor will it convert anything. This is for testing only.)
pex hierarchy	permissions.manage.users	Print the complete user/group hierarchy
pex import <backend>	permissions.manage.dump	Import users/groups from selected format
pex users cleanup <group> [threshold]	permissions.manage.users.cleanup	Remove "dead" users from the file. [threshold] is in days and defaults to 30

World Inheritance Management

pex worlds	permissions.manage.worlds	Print the worlds PEX and the server know of
pex world <world>	permissions.manage.worlds	Print the <world> inheritance info
pex world <world> inherit <parentWorlds>	permissions.manage.worlds.inheritance	Set the parent worlds for <world>. <parentWorlds> can be just one world, or a comma-separated list of worlds.

User commands

pex users list	permissions.manage.users	List all users defined in the permissions file
pex users	permissions.manage.users	List all users defined in the permissions file (alias to users list)
pex user	permissions.manage.users	List all users defined in the permissions file (alias to users)

User's permission management

pex user	permissions.manage.users	List the registered users
pex user <user>	permissions.manage.users.permissions.<user>	List the permissions for <user> (alias to user <user> list)
pex user <user> prefix [newprefix]	permissions.manage.users.prefix.<user>	Get or set the prefix for <user>
pex user <user> suffix [newsuffix]	permissions.manage.users.suffix.<user>	Get or set the suffix for <user>
pex user <user> delete	permissions.manage.users.<user>	Remove <user> from the permissions file
pex user <user> list [world]	permissions.manage.users.permissions.<user>	List the permissions for <user> . Shows the permissions assigned to the user directly as well as those assigned via the group the user is a member of.
Specify [world] to list the users permission for a single world
pex user <user> add <permission> [world]	permissions.manage.users.permissions.<user>	Add <permission> to <user>. Specify [world] to grant/deny  permission only in [world]
pex user <user> remove <permission> [world]	permissions.manage.users.permissions.<user>	Remove <permission> from <user>. Specify [world] to remove permission only from [world]
pex user <user> timed add <permission> <lifetime in seconds> [world]	permissions.manage.users.permissions.timed.<user>	Add timed <permission> to <user> for <lifetime in seconds> in [world]
pex user <user> timed remove <permission> <lifetime in seconds> [world]	permissions.manage.users.permissions.timed.<user>	Remove timed <permission> from <user> for <lifetime in seconds> in [world]
pex user <user> set <option> <value> [world]	permissions.manage.users.permissions.<user>	Set <option> to <value>. Set value to "" (two double-quotes) if you want to remove the <option>. Specify [world] to set <option> only in [world]

User's group management

pex user <user> group list	permissions.manage.membership.<user>	List all groups the <user> is currently in
pex user <user> group add <group> [world] [lifetime]	permissions.manage.membership.<group>	Add <user> to <group>. Optional param lifetime (in seconds) is used to make timed membership. You can replace world by "" if the group of the user is applied for all worlds and you want applied a lifetime.
pex user <user> group set <group> [world]	permissions.manage.membership.<group>	Set <user> group to <group>. Note that this command removes the user from any other groups they are a member of.
pex user <user> group remove <group> [world]	permissions.manage.membership.<group>	Remove <user> from <group>

missing: /pex group weight [weight] print or set group weight

Default groups management

pex default group [world]	permissions.manage.groups.inheritance	Print the default groups for specified world. If [world] is not specified, it will apply to the global config.
pex set default group <group> <value> [world]	permissions.manage.groups.inheritance	Set the default flag of <group> in [world]. Any number of groups can have this flag set. If [world] is not specified, it will apply to the global config. <value> is boolean 'true' or 'false'.

Group commands

pex group	permissions.manage.groups.list	List all registered groups (alias to groups list)
pex groups	permissions.manage.groups.list	List all registered groups (alias to groups list)
pex groups list	permissions.manage.groups.list	List all registered groups
pex group <group> prefix [newprefix]	permissions.manage.groups.prefix.<group>	Get or set the prefix for <group>
pex group <group> suffix [newsuffix]	permissions.manage.groups.suffix.<group>	Get or set the suffix for <group>
pex group <group> create [parents]	permissions.manage.groups.create.<group>	Create <group>. Specify [parents] to set the groups it inherits from
pex group <group> delete	permissions.manage.groups.remove.<group>	Remove <group>
pex group <group> parents list	permissions.manage.groups.inheritance.<group>	List the parents for <group>
pex group <group> parents set <parents>	permissions.manage.groups.inheritance.<group>	Set the parent(s) for <group> (single or comma-separated list)
pex group <group>	permissions.manage.groups.permissions.<group>	List all <group> permissions (alias to group <group> list)
pex group <group> list [world]	permissions.manage.groups.permissions.<group>	List all permissions for <group>. Specify [world] to list the group's permissions for [world]
pex group <group> add <permission> [world]	permissions.manage.groups.permissions.<group>	Add <permission> to <group>
pex group <group> remove <permission> [world]	permissions.manage.groups.permissions.<group>	Remove <permission> from <group>. Specify [world] if this permission should be removed only in [world]
pex group <group> timed add <permission> [lifetime] [world]	permissions.manage.groups.permissions.timed.<group>	Add timed <permission> to <group> with [lifetime] in [world]
pex group <group> timed remove <permission> [world]	permissions.manage.groups.permissions.timed.<group>	Remove timed <permission> for <group> in [world]

pex group <group> set <option> <value> [world] permissions.manage.groups.permissions.<group> Set <option> <value> for <group>. Set value to "" (two double-quotes) if you want to remove the <option>. Specify [world] if the option should be set only in [world]

Group's user management

pex group <group> users	permissions.manage.membership.<group>	List all users in <group>
pex group <group> user add <user>	permissions.manage.membership.<group>	Add <user> to <group> (single or comma-separated list)
pex group <group> user remove <user>	permissions.manage.membership.<group>	Remove <user> from <group> (single or comma-separated list)
pex promote <user> <ladder>	permissions.user.promote.<ladder> (if there is only one ladder, it will be named default)	Promote <user> on <ladder>. If <ladder> is not specified, the default ladder (named default) will be used.
pex demote <user> <ladder>	permissions.user.demote.<ladder> (if there is only one ladder, it will be named default)	Demote <user> on <ladder>. If <ladder> is not specified, the default ladder (named default) will be used.

FAQ

Features

Integrating with PEX

Migration

Migration and UUIDs

Modifyworld

Pex basics

PEXML

Plugin Configuration

Ranks (Promotion and Demotion)

Troubleshooting and FAQ