Permissions FAQ

Discussion in 'Plugin Development' started by Dinnerbone, Jul 7, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    @4am I knew everything you said already, I was asking because I wanted to know if it was possible to say for example do:

    /warpgroup ducks

    and warp all players in the group ducks to somewhere. I just wanted to know if it was there, because I couldn't find it in the API. I know different ways to do it, I just wanted to know if it was possible.

    But still thanks for your information =D
  2. Offline

    Celtic Minstrel

    Though, I think he was asking for suggestions to replace "Permissible", ie something that has permissions, not to replace "Permission".
  3. Offline


    That is what I meant to supply. Permissions are assigned to Principals.

    I still haven't found time to look closer at it though... perhaps I'm still misunderstanding. Is Permissible more of an object that represents a resource a principal might try to access?
  4. Offline

    Celtic Minstrel

    Ah, I see, I simply was not aware of that use of terminology. The term "Principal" does fit what Permissible is supposed to mean, then.
  5. Offline


    Ah, yes I see. Again though, no way to do that. Bukkit's API only manages nodes, it doesn't care about how those nodes are assigned (and therefore doesn't know about groups).

    In a case like that I'd set up your plugin like I show in my second example; either the permissions-manager plugin will assign users within a group a specific node to show they're part of that group (perhaps permbook.groups.ducks: true) or the server admin will use permissions.yml to group all the nodes needed for yourgroupname's members under serverperm.ducks; your plugin will need to ask what nodes to find groups under such as
        message: 'then he stopped and all the other ducks went mental; it looked just like duck stand-up comedy'
    You code will have to be smart enough to take the string "permbook.groups." and add the /warpgroup command's parameter and pass that to hasPermission() while looping through all the users.

    This is why I an hoping that permission changes will trigger events within Bukkit (NOT custom events from a plugin) - looping through 100+ users and doing a string compare on god knows how many assigned nodes might be alright on the occasional group warp, but if this is something that happens frequently (i.e. every 30 seconds the users in ducks get healed 5 points) then this is going to be a lag issue on big servers, unless the groups can be calculated on the fly (in which case we need events to watch for the perm change) or Bukkit needs to support groups (unlikely).
    Elusive92 likes this.
  6. Offline


    @4am That's exactly what I had in mind, and I fully agree with your thoughts about events.
  7. Offline


    It sounds to me you're re-inventing the wheel - this is what Bukkit is implementing. Currently many plugins will hook into the Permissions plugin, so plugins like GroupManager and Lists actually designed their API to pretend to be the Permissions plugin. As it stands now, I'm sure none of these plugins are going to offer their own direct API hooks now that Bukkit has created a central-repository style API, so I'm thinking you might not need to re-create this functionality as the permissions plugins themselves are very likely to be converting over to Bukkit's system.

    Those plugins will still be needed to handle in-game commands, groups, and any other features beyond adding/removing permissions and .hasPermission(). This way, server admins can choose their favorite Permissions system (or develop their own) and other plugins just need to hook into Bukkit's .hasPermission and not sweat the differences in management plugins.

    EDIT: This system also allows *any* plugin to assign a permission - a user wins a lottery and the lotto plugin can assign, say, access to PortalStick for 24 hours or something.
  8. Offline


    I honestly don't see how this has ANY benefits over the current Permissions 2.x plugin. You're taking away the node-based structure, the ability for easy wildcard permissions, the concept of groups (Which is something I dare say 99% of servers probably use), but still requiring a third-party plugin to actually manage the permissions.
    So I must ask, what is the benefit of this over the currently implemented Permissions 2.x plugin? Other than "It's recommended by the Bukkit team" of course.
    arpey, phaed and Jesse9640 like this.
  9. Offline

    Celtic Minstrel

    The benefit is that plugin developers don't need to build against the Permissions plugin. The Permissions plugin will tell Bukkit what permissions each user has, and then your plugin will query Bukkit rather than Permissions to determine if a user has a permission.

    The node-based structure and easy wildcards (except for plain *) is easily replicable, though it can get a bit tedious if you have a large permissions tree.
  10. Offline


    More work for plugin developers to get the same outcome seems like bad design practice

    There's also the fact we're taking a step backwards. Most servers using Permissions right now are completely based around users AND groups, with a sprinkling of variables. By removing both groups and variables you remove a large chunk of flexibility that Permissions offers.
    arpey, phaed, Mukrakiish and 3 others like this.
  11. Offline


    I don't see where there's more work for plugin developers (except the developers of the Permissions-like plugins).

    99%(*) of plugins just need a way to ask if a player has the permission for "<pluginname>.some.node". Now those plugins just need to do 'if (player.hasPermission("pluginname.some.node")) { // stuff }' and add the name of the node to plugin.yml.
    Previously, those plugins had to check which permissions plugin is available and add a reference to that plugin or its handler to the class.

    If you write one of the many plugins that needs chat prefixes/suffixes, you just use the old Permissions API.

    (*) completely made-up value

    He's not removing groups. Groups are handled by the backend plugin(s) which interpret(s) the configuration file.

    And what do you mean with variables? non-boolean permissions? I would agree with that, but those should be handled by a different API, since chat prefixes/suffixes, join messages, or whatever you need them for, are not something you would call a 'permission'. I would suggest to build another API for this purpose, which would allow arbitrary attachments/attributes for Player objects.
  12. Offline


    @Zeerix More work for plugin devs in the fact we now need to completely plan out our Permissions tree and write up a config file like so:
            description: Gives access to all doorman commands
                doorman.kick: true
                doorman.ban: true
                doorman.knock: true
                doorman.denied: false
            description: Allows you to kick a user
            default: op
            description: Allows you to ban a user
            default: op
            description: Knocks on the door!
            default: true
            description: Prevents this user from entering the door
    As opposed to having this tiny bit of code:
    Plugin plugin = pm.getPlugin('Permissions');
    if (plugin != null) permissions = (Permissions)plugin;
    And then to check a permission
    function hasPerm(Player player, String perm, Boolean def) {
        if (permissions != null && permissions.isEnabled()) return permissions.getHandler().has(player, perm);
        return def;
    That is far easier to implement if you ask me. This new system is a step backwards in features, usability for devs, and flexibility for admins. Atleast that's how it's appearing so far.

    A question, since this is the FAQ topic. Are admins able to supply a specific user with ALL nodes in a tree minus one? (stargate.* -stargate.destroy for example). From the fact they are no longer calling it node-based, and are instead refering to them strictly as permission strings I'm assuming no?
  13. Offline

    Dinnerbone Bukkit Team Member

    Using your example, things don't default to op when they should. There's no descriptions if people want to find out what a permission node does. Easy to implement? Sure. You can also do that with the new system, just don't define those permissions. Easier on the user? Hell no.

    If you define a permission ("parent") which includes another permission ("child"), you can just child:false and they won't have that permission anymore.
  14. Offline


    That would be the job of your Permissions mangement plugin; Bukkit itself has no support for anything other than true/false values for specific nodes; it' snot even stored in a tree structure. You permissions plugin would need to set up each node in response to your configuring "stargate.* -stargate.destroy".

    All Bukkit's system is for is to create a universal interface to determine if a specific action is permitted at any time. That is it; it's very minimal. This means that any plugin that wants to implement its own system of organising permissions can, without having to match the current standard of the Permissions plugin. It's just an official interface for a commonly implemented system.
  15. Offline


    Fuck yeah.
  16. Offline


    cna i just ignore the permssions option and keep using permissions 2.7.4? without hassle?
  17. Offline


    So... If I want to give someone the permission to use the "/give" command, I have to write something in the "permissions.yml" file ?

    But... how does it work ? What do I have to write in it ? ^^;
  18. Offline


    Needs a good tutorial of how to use permission nodes in permissions.yml, mine is just sitting there empty D:
  19. Offline


    So, are there any plugins atm that tell bukkit which players should get which permissions when? Btw, what exactly does this mean? Is it simply stating how people are demoted/promoted or is it saying how people are put in a certain category to start with? Sorry, a bit confusing to me.
  20. Offline


    Pls , needs an example on how to use this bukkit permissions I need different groups that can do different ... like some group can only tp or a group can only "give" ....something like this ... Pls :)
  21. Offline


    Bukkit's permisions don't do that, you still need a 3rd party plugin that does groups and things of that sort. Someone is working on a default permissions plugin that will do groups and things that permissions 3.x does but its not out quite yet.

    edit: If I understand it correctly its sort of like a solid base that is universal, and so plugins wouldn't have to say support a particular permissions system, they would just have to support bukkit permissions. The plugins that would utilize groups/other features would be working on top of this base.
  22. So apart from creating a custom event and firing that off, how would one create a group that contained permissions from multiple plugins?

     - multiverse.core.blahA
     - multiverse.core.blahC
     - multiverse.core.blahD
     - multiverse.portals.blahA
     - multiverse.portals.blahC
     - multiverse.portals.blahD
     - multiverse.netherportals.blahA
     - multiverse.netherportals.blahC
     - multiverse.netherportals.blahD
    Apart from creating a custom event, and collecting all of the commands in the sub-plugins, that depend on core, is there a way to do this?

    I also have a bit of a problem not being able to delete a permission, for example:

    Core uses permissions for world entry:
     - multiverse.core.access.world_nether
    If a user creates a world, deletes that world (all of this is possible from within MV-Core) there is an abandoned permission. This is even more of a problem for MV-Portals, as this is the same way perms work there, apart from the fact that portals can be renamed...

  23. Offline


    I haven't seen how you're tracking permissions, but is it not possible to just map one node (or string or however they're stored) to a list of nodes/strings that reference it, and only update that on when un/setting one permission as a child of another? If nodes are actual objects, just include the list directly in the node object and when shutting down just go through and clear these lists in order to solve the circular reference issue? I'll admit I'm not super-familiar with the setup, but is it really that hard to set up a parents-list for the nodes? Or could you give a more in-depth reason why this is unpractical?
  24. Offline


    Tiny and – ugly. Sorry, to say this, but if you want to implement Permissions support right (with plugins, not with this API here), you have to do more than this. For example, if you want to support other plugins than the Permissions plugin. What is, if the Permissions plugin isn't already enabled, when your plugin get enabled? Or the other way around (as you couldn't cover both cases with the same test)? Many plugins simply ignore this, and force enable the Permissions plugin. They don't even tell this to the server admin that they enable the plugin. So if I disabled the Permissions plugin, to test something without it, and then enable the other plugin. No chance, the Permissions plugin get enabled (argh is this worse :( ). And then there is the possibility, that the Permissions plugin gets disabled, while other plugins uses this. Now as far as I can see, your example is working without the Permissions system. So you don't force enable the plugin, and it doesn't crash when the plugin gets disabled. But everybody who isn't doing this extra stuff or essentially need Permissions will fail there.

    And then: This Bukkit API provide a standard API. Like every standard there are advantages (better interoperatbility and works more stable) and disadvantages (maybe more complex/new stuff to learn/review).

    And to be fair: At the moment I don't know how to adopt this into my plugins :/ I have one question: I don't understand the purpose of the permissions nodes in the plugins.yml file:
    My guess would be: These nodes define 4 (or 5?) permissions (doorman.{kick,ban,knock,denied}) and if a plugin tests for example the permission “doorman.knock” it will return (if not defined otherwise somewhere else) true?
    Now what does the “doorman.*” do? And what is the default of “doorman.denied” or more generally, if no default is defined? And every permission node have to be registered either this way, or with the getPluginManager().addPermission(new Permission(.....)) code?

    And another question related to the groups: At the moment I'm working on my plugin to support groups. For example it is possible to say: Group “foo” has access to the warp “bar” and could do “this”. Now as this doesn't support groups my first approach would be, to define a node instead of a group. So everybody with the node “” has the access and could do something with the warp. Now there are some little contras: The node itself is far longer than the group and the group name is more plugin (everybody on my server could name the group in which (s)he is, but not the permissions the user has). Is there maybe another nicer way?

    So this was it with asking :) I have only one wish left: User/Group values as it is possible to define values for a user/group in Permissions 3 (for example the warmup/cooldown) and xWarp is using a lot of such stuff :p

    And thanks to the developers of this SuperPerms. Now Bukkit have a default permissions API :)

  25. Offline


    Hopefully things will all work out and it will be just as easy as it is now.
  26. If I understand correct (about the code example) you can place this in your plugin.yml, and not have to worry about definining the permissions in your actual code. This will do it for you. As for the true/falses, these are children, and the true/false means that a person that has that parent, has those children.

    So if you gave me dooman.* i would have doorman.kick, ban, knock but NOT denied. This is neat for small plugins, and my other plugins will love this, but for something as complex as Multiverse that extends beyond the borders of a single plugin, this is a little rusty.

    If i'm wrong about how this works, someone, please correct me.
  27. Offline


    So could a mod set up group definitions within its own permissions, partially through inheritance? e.g.
            description: Gives access to most doorman commands
                doorman.kick: true
                doorman.ban: true
                doorman.knock: true
                doorman.denied: false
           description: Gives limited access to doorman commands
                doorman.kick: false
                doorman.ban: true
                doorman.knock: false
                doorman.denied: false
            description: Gives access to all doorman commands
             default: op
            description: Allows you to kick a user
            default: op
            description: Allows you to ban a user
            default: op
            description: Knocks on the door!
            default: true
            description: Prevents this user from entering the door
  28. Offline


    Hmm... still trying to wrap my head around this system however I can't see how it would work with my current work on OtherBlocks. I'm using the permissions inheritance and wildcards to allow players to create custom nodes for allow/disallowing custom drops in a very flexible manner.

    # Permissions:
    # In the example below you need to give the player or group the
    # '' permission to drop the glass block.
    # Giving them '' as well will add the pain
    # and giving '*' will give both.
    #    GLASS:
    #        - tool: ANY
    #          drop: GLASS
    #          quantity: 1
    #          permissions: "glass"
    #        - tool: AIR
    #          drop: NOTHING
    #          damageattacker: 2
    #          permissions: "glass.pain"
    #          message: "Ouch! That hurt."
    #          chance: 25
    Using this (and a "permissionsexcept" option) allows server admins to create their own permissions structures and child/parent relationships.

    Having the dot notation automatically assign subnodes as children is very useful and not having this in the default permissions system (even if another plugin does replicate this) means I cannot rely on every user having this feature.

    Manually adding children seems a bit confusing, if I do this:

            description: Gives access to all doorman commands
                fred.kick: true
                thingy.ban: true
                blah.fred.knock: true
                fred.thingy.blah.denied: false
    Would fred.kick/etc be a child of doorman.*? Seems like (whilst we wouldn't want them to do so) this allows plugin authors to break expectations potentially creating very confusing systems as per above.

    Also, what happens if two plugins use the same permissions names with different children?
  29. Offline


    Okay, everyone, not to sound like a noob, but how do I actually set permissions? I see all of these things saying different lines to put in the permission folder, but I'm not sure how to do this. Any detailed guide would be extremely helpful for all others like me.
  30. Offline


    I love you all
Thread Status:
Not open for further replies.

Share This Page