Permission inheritance and command flags

Sponge’s permission handling provides an implicit inheritance. As the java-docs of the Subject state:

Inheritance is implicit; that is, if a subject has been granted example, then the subject should have also be automatically granted example.function, example.another, example.deeper.nesting, and so on. However, implementations may allow administrators to configure “negation” such that example and all child levels would granted but example.access would denied (for example).

I am unsure how to handle this inheritance in the following example (taken from my MyWarp plugin): The command /warp give [-df] <player> <name> gives a warp to another player. It comes with two optional flags: d gives the warp directly, f ignores any limit checks of the receiving player. Permissions are defined as:

  1. mywarp.warp.soc.give - to use the command without any flags,
  2. mywarp.warp.soc.give.direct - to use d,
  3. mywarp.warp.soc.dive.force - to use f.

While it seems natural that (2) or (3) also give the permission to use the command without any flags, it is (1) I worry about. Due to Sponge’s implicit inheritance it would also provide access to (2) and (3) with is not intended.

So how am I supposed to define the permissions in such a case? What is the best practise as required by Sponge’s permission handling? Must I enforce explicit negation by end-users (sound like a usability nightmare)? Should I use something like mywarp.soc.give.usage instead of (1)?

maywarp.warp.soc.give.give
maywarp.warp.soc.give.direct
maywarp.warp.soc.give.force

???

I think Sponge’s permission system is a complete nightmare :frowning:

What would have been great is a system that supports node.* notation and explicit inheritance.

Well, it’s not too late…

2 Likes

Yeah, that anyway :stuck_out_tongue:

This would certainly work, my question is rather what the ‘official’ or best practice solution is in such a case. Or, to put it differently, if this solution is the recommended one.

On another node, this is something that probably should be covered by the permission API article in the documentation that is currently empty.

I would say that it is the recommended solution.

I opened an issue to discuss the permission system: Rethink permissions · Issue #494 · SpongePowered/SpongeAPI · GitHub