Permission System

Please refer to

As of update 2.4.0 old permission nodes are now invalid.

The new system is now analog to the config dependend guest node system.

All nodes follow that order. Guest nodes (not logged in) count for all even ops so you now you can really restrict permissions.

To make your life easier you can enable permissions.debug via xauth config permissions.debug true to enable permission debugging (No reload or restart needed).

Note: that this will fill up your log quite quickly if you have many players on your server. I will give you a filter for players in a next version so for now you will have to filter it yourself.

Example taken from config.yml

            chat: true
            interact: true
            move: true
            pickup: true
                register: false
                login: false
                l: false
            damage: true
            regain: true
            level: true
            splash: true
            target: true
            place: true
            break: true
            damage: true
            target: true

Everything set to true will be disallowed. If you dont add a permission node it will be denied per default for guests.

Note: A guest is someone who didnt authenticated. If he is registered but not logged in he still will count as guest if not authenticated. Even OPs will be restricted to the guest system. No excludes.

An authenticated player has two different nodes. Instead of guest.restrict he will have two nodes:

  • xauth.allow.*
  • xauth.restrict.*

Why two nodes? Well as the system allows you to also deny commands and specific arguments and interaction (like Modifyworld) and i did not want to interfere with that it has two states instead of the negative permission.

I also didnt like the current permission system as the config checks for "is it there" and from my point of view no additional logic should be implemented to check for "it is there but it counts as false".

So if you want to disallow a permission dont use -xauth.allow use xauth.restrict! you still could use -xauth.allow technically but i would not recommend as it will be easier to read if you use xauth.restrict instead.

Example for authenticated players taken from plugin.yml

  • xauth.allow.player.command.login
  • xauth.allow.player.command.xauth.changepw
  • xauth.allow.player.move.player.playerName
  • xauth.allow.entity.damage.player.playerName

So if you want to allow everyone in a group to chat and you added in an inherited group just add or depending on plugin used* as permission cause after the node chat "<entityType>.<entityName>" is added to limit it to the entity if needed.

Note: allow is default so if its not there its allowed. You only need this if one user is in multiple groups. For example you allowed chat in one group. Then you would use * to disallow that player to chat. The opposite would also work.

I hope that this is all you need to know about the new permission system. A detailed version of this will be available on my confluence documentaiton. For the time beeing i have added a cheat sheet to the footer. This document is only a quick wrapup for you to get started quickly.

If you have any comments or improvements to shout out please post them on my jira at in project xAuth. I will read comments but if you want me to work on something please add it to my jira.

Checkout the Permissions Cheat Sheet for a quick overview of the new system by clicking on the image below.
(This will open the full sized image in the current window)