PermissionsEX

本页面已存在其他语言的内容，请协助翻译为本地化的中文。

• 点击此处开始翻译。
• 如本模板出现在原文存档页面，请注意更新主页面后，仍需要去除此处该模板。
• 如当前页面已经没有需要翻译的内容，请删去待翻译模板。
• 有标题的大篇幅文章，如果短时间内无法全部翻译，请先把所有的标题翻译出来，以便之后的贡献者选择与翻译章节内容。

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.

Advanced permissions setup

Permissions Inheritance

Many servers are configured to have multiple groups, with each group in the ranking adding new permissions as a player advances. Permissions inheritance allows the admin to configure this while minimizing the amount of duplicated nodes for each group.

This section assumes that you have successfully completed the Basic Permissions Setup tutorial. If you haven't done this yet and you want to start directly with this tutorial, it is not guaranteed that you will understand each step here as this tutorial builds upon the earlier sections.

Using the example from the Basic Permissions Setup, you may have noticed that the Member, VIP and Moderator groups all share a permissions node, the modifyworld.* node. This is unnecessary with inheritance.

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插件提供了一些用于保存权限数据的后台，这个页面会解释所有） 但其实这个页面只有这一句话（或许是服务器问题） 所以请等待更新。

Basic Permissions Setup

Permission Nodes

PEX works on the general principal that permission to run a command is not allowed unless the permission node is specifically listed. For those commands and events that are allowed by default, PEX allows for denying access to those commands with permission node negation.

Giving or denying access to a permission node is as simple as using the pex group <group> add <node> command. Negating a permission node uses the same command, you just need to add a hyphen (-) to the beginning of the node name.

For example, lets look at the /give and /plugins commands as they are part of bukkit.

/give has a permission node of bukkit.command.give and is normally limited to players listed in the ops.txt file /plugins has a permission node of bukkit.command.plugins and is normally given to everyone on the server The commands to add or deny access to these commands are:

To allow a group access to /give, the command for PEX is pex group groupname add bukkit.command.give To deny a group access to /plugins, the command for PEX is pex group groupname add -bukkit.command.plugins

Important Information on the '*' Node

PEX does support a 'give all permissions' node with '*'. However, before using this, read and understand how it works and it's possible side affects. At first glance, it seems simple, giving a group '*' gives it access to all permission nodes. The catch is that there may be permission nodes that you normally would not want a group to have. For example, consider the plugin VanishNoPacket (Referred to as VNP.) VNP offers the node vanish.silentjoin which makes anyone with the node log into the server without a join announcement, which many server owners do not want. This behavior can be simply dealt with by negating the node. Any permission node that is enabled by default can be negated to "turn it off".

Important File Back-end Notes

If you are going to edit the permissions file by hand, make sure to read, understand and follow these rules:

Permission nodes must start with a hyphen and a space. - modifyworld.chat and - -modifyworld.mobtarget.* are valid entries in the file back-end modifyworld.chat and -modifyworld.mobtarget.* are invalid entries in the file back-end All formatting rules listed in the YAML notes section on the PEX Basics page must be strictly followed. Failure to do this can and often does cause PEX to fail on startup, as well as filling your log files with great amounts of error message text. PEX reads the file in a 'top to bottom' manner when checking group and user permission nodes. Similar to a network firewall, once it finds a node that matches what it is looking for, it stops searching. What this means in practice is that if a node gives access to a main group and all subgroups, PEX will find the node that allows access then stop checking, never reaching the negation node. Consider the following (incorrect!) example:

default:

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

With this node layout, if a player tried to open a dispenser (data value 23), the first match would be modifyworld.*, causing PEX to stop checking at this point and allow access!

However, if the two lines were reversed (-modifyworld.blocks.interact.23 came before the modifyworld.*), the player would be denied when trying to open the dispenser (node check modifyworld.blocks.interact.23) as the negation node for block ID 23 is the first one to be matched. If the player tried to open a furnace (block ID 61), it would be allowed as the modifyworld.* node would match a check of 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.*"
     ]
   }
 }

}