Permissions FAQ

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

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

    ToastedJelly

    Keep your normal permissions for now and watch this thread. This isn't ready for prime time.
     
  2. Offline

    Mixcoatl

    I'm frustrated and disappointed.

    I need strong support for group management. Specifically: I need, at a bare minimum, to be able to create and remove groups dynamically, add and remove players from groups dynamically, determine which groups a player is a member of, an which players a group contains.

    Some bullets:
    • Groups as a tertiary usage of permission nodes meets the bare minimum need.
    • Dynamically must be interpreted as meaning, "while a plug-in is operating, and without requiring permissions to be reloaded." If there is a programmatic way to reload permissions using only the Bukkit API, this would be sufficient.
    • I absolutely cannot afford to create a dependency on an external plug-in that a server operator may choose not to use, so this functionality must be supported through the Bukkit API interfaces, even if it is implemented by the permission attachment (?).
    Permissions are useless to me without at least this much.
     
    phaed and Lunar Delta like this.
  3. Offline

    Celtic Minstrel

    I guess you would need to either make the extra plugins soft dependencies and create the parent permission dynamically once the core loaded, or start creating the permission as soon as you load but then have an API call that the other plugins can add to expand on the permission. In the latter case though, I'm not sure how you'd complete the actual process of creating the permission once all possible plugins have loaded, since permissions are immutable.

    Actually, I guess I also have this in General with kit permissions... I think you'd just have to leave the dangling permissions there for now, but having a delete permission option does sound like a good idea.

    I think you'll need to gather all the various nodes that people use into a central place and, once the config is loaded, sort through them and build the permission hierarchy dynamically.

    Yeah, plugin authors can break expectations with this. They could even create a permissions node called "fred of the jungle$$123" if they wanted to.

    Trying to add a permission that already exists raises an exception. I imagine this would apply even for permissions defined in the plugin.yml.
     
  4. Offline

    Brandon Egnell

    ok im just having difficulties at the moment. I dont understand what the format is for permissions.yml or are we to use the superperms and bridge to do our permissions. Or can i stick with what i know (group manager) it may not be the best but there are going to be some learning curves for me here if i cant understand the way its all meant to be put together.

    If you can just give me a format for one thing that i could work off of.
     
  5. Offline

    fugue2005

    how about giving us server owners an example permissions.yml so we can know what to expect.
     
  6. Offline

    Zarius

    Hmm... I see how I can loop through the custom permissions from my config and create a ".*" permission node as the parent for each group of subnodes. It still seems so counter-intuitive that one could have:

    Code:
    permissions:
        doorman.*:
            description: Gives access to all doorman commands
            children:
                doorman.kick: true
                doorman.ban: true
                doorman.knock: true
        doorman.kick:
            description: Allows you to kick a user
            default: op
        doorman.ban:
            description: Allows you to ban a user
            default: op
        doorman.knock:
            description: Knocks on the door!
            default: true
        doorman.denied:
            description: Prevents this user from entering the door
    
    And now the giving doorman.* does not give doorman.denied? Seems very prone to developer error as well if they forgot to add a particular node as a child.

    If conflicting permissions result in an exception for the latter one I don't see the problem with allowing doorman.* to provide all subnodes (eg. doorman.blah, doorman.1.2.3, etc) as no other plugin can register/create the "doorman" permission.
     
  7. Offline

    dwdminecracked


    Hmm how about with world guard? For Example:

    Code:
    permissions:
            worldguard.region.*:
                    description: Gives access to all worldguard commands
                    children:
                            worldguard.region.flag.own.*: true  [can that work? or you have to write out all the regions they own?]
                            worldguard.region.flag.flags.*.owner.*: true [Would the 1st '*' work or I would have to right all the flags out?]
                            worldguard.region.setparent.own.*: true [Is this able to work or am I going having to wait for a fix of some sort?]
    
                             world....etc....
    
    I have other plugins that use that type of node would it work or is that something that I would have to wait for the plugin creator to work on? I do not have this implemented yet, still using bukkit #953.

    ps: if I made no sense I sorry its 4:09am very tired atm lol

    EDIT: Hmm another concern, well question pop to my head, when you are adding multi-worlds into the Mix for the permission part is that for the default world and the other worlds you add in the WORLDS: section or do you add all worlds in the worlds section n in the permissions section you add nothing?

    Examples:

    Code:
        Guest:
            permissions:
                permissions.build: false
                essentials.geoip: true
                essentials.rules: true
                essentials.spawn: true
                lwc.blockinventory: true
                essentials.motd: true
            worlds:
                creative:
                    essentials.geoip: true
                    essentials.rules: true
                    lwc.blockinventory: true
                    essentials.motd: true
    
    OR

    Code:
        Guest:
            permissions:
                permissions.build: false
            worlds:
                creative:
                    essentials.geoip: true
                    essentials.rules: true
                    lwc.blockinventory: true
                    essentials.motd: true
                survival:
                    essentials.geoip: true
                    essentials.rules: true
                    lwc.blockinventory: true
                    essentials.motd: true
    
    I know they both have same perms but others groups does not, have over 20 groups on our server. Little confused on this part
     
  8. Offline

    7eggert

    I think you'll use a hash table to store the calculated permissions. So if you ask for foo.permission, you'll first look at calculated_permissions["foo.permission"], then failing that look at defined_permissions["foo.permission"] and parent_permissions["foo.permission"] (e.g. finding foo.* is (one of) the parent(s)) and recurse. If the permission was calculated using defined permissions/parent dependencies, you'll store it in calculated_permissions.

    If a plugin adds "foo.permission" later, you can delete calculated_permissions["foo.permission"] and delete it, but if somebody adds "foo.permissiongroup" being a parent of "foo.permission", you'd have to clear calculated_permissions or do a complete hash walk, which would even cost more. Doing this automatically would be insane.

    I'd suggest allowing a direct definition to override a cached result (as described above) and to provide a "/permissions flush [cache|parents|all]" command to clear the cache, so e.g. a plugin having reloaded it's permissions file could update the server.
     
  9. Offline

    ToastedJelly

    I also like the ease of *, especially withPlugings that create that hierarchy on the fly for every block/item type etc.
    How can you specify to allow all blocktypes and disallow a small list?
    How it is setup now, with updates on blocks, either the admin needs to add those block permissions or the plugin author needs to publish a new version, even if the code didn't change at all, just to make sure ".*" includes the new block IDs.

    The thing is... if this really stays that way, we just have to say goodbye to the .* semantic.
    For not confusing anyone it's best to educate everyone that .* doesn't exist with the current system anymore and if you need groups_of_permissions/child-permissions, just give them an appropriate name and don't use *

    Like:
    Code:
    permissions:
        doorman.sets.moderator:
            description: Gives access to moderator doorman commands
            children:
                doorman.knock: true
                doorman.denied: true
        doorman.sets.admin:
            description: Gives access to admin doorman commands
            children:
                doorman.kick: true
                doorman.ban: true
        doorman.kick:
            description: Allows you to kick a user
            default: op
        doorman.ban:
            description: Allows you to ban a user
            default: op
        doorman.knock:
            description: Knocks on the door!
            default: true
        doorman.denied:
            description: Prevents this user from entering the door
    Or am I overlooking something here? I didn't check the API yet, but if the implementing permission class is asked every time when .has() is called, what keeps it from implementing the * semantics?
     
  10. I'm disappointed that the same approach used for custom map generators (provide just an interface and a manager and let the plugin dev worry about backend storage/permission resolving/implementation) wasn't used and instead what seems a slightly clunky frontend was made instead where we lose key benefits of the current system (metadata storage for groups and wildcard resolving).

    I just don't see the benefits outweighing the costs here.

    From what I can tell, a permission plugin must specify All allowed nodes, instead of being able to calculate them on the fly and then cache the result.

    I can't see the sense in forcing us to cache the result inside of the bukkit API, when it could just as easily have passed the query to a plugin implmenting a permissions interface.

    I also have to raise a query, I see no confirmation of whether this interface supports multiworld. on some servers this is an absolute must.
     
    phaed and dwdminecracked like this.
  11. Offline

    Zeerix

    It supports Multiworld in the way that you can change the attached permissions as soon as a player goes to another world.
     
  12. Offline

    Raphfrk

    Could a method be added to the API.

    Player[] getAllowed(String permission);

    This would return all players who have that permission.

    getAllowed("group.<group name>")

    could be the unofficial official group node.

    A plugin could easily scan though all players anyway, so no big deal. The only reason to have the method (other than convenience) is if there was some internal node -> Player lookup.

    Also, it would be nice to have non-boolean permissions.

    Integer getInteger(String permission)
    Integer getString(String permission)

    A permission could in theory store a string and an int.

    This would allow things like chat prefixes and setting timeouts and other limits for players.
     
    xZise likes this.
  13. Offline

    xZise

    Yep, I mean why define the . and the * as “special permission name characters” which seperates a permissions. Actually, you also could use only the asterisk as a special character as there is no difference between foo.bar.* and foobar*. If the plugin defines the permissions foo.bar.snafu and foo.bar.leet or foobarsnafu and foobarleet both are granted. The first one is only better to read.

    But as far as I get this right, a permission plugin still can use the asterisk notation. I mean normally a plugin asks if the user has foo.bar.snafu permission. Only if a plugin defines a permission name with a asterisk this could be complicated.

    Isn't this also possible, with the “old” fashioned system?


    And these children things are acting like a shortcut? So a server admin either define doorman.* or the doorman.{kick,ban,knock} for the player with no difference? It is some kind of confusing, as the plugin developer could interfere with the permission configuration by the server admin.

    Fabian
     
  14. So multiworld permissions have to be reloaded everytime someone Teleport's? Where is the performance bonus in that? Also, am I right in thinking that permissions are duplicated across people in the same "groups".
     
  15. Offline

    Zarius

    Don't discount readability... also, with "foobar*" what happens if the player uses "fooba*"? With the dots "star.gate.open" and "stargate.open" are two completely different branches, without the dots they are the same. I see it similarly to folder names - eg. "cprogramfilesjavabinstuffhelptxt" isn't very readable or practical (is the folder "javabinstuff" or "java/binstuff" or "java/bin/stuff"?).

    No, this is not possible - "doorman.*" would never match "fred.kick" in the old system.
     
  16. Offline

    xZise

    This depends on the plugin developer. At the moment the name could be everything and no character has a special meaning. Now previously there was a special meaning for the asterisk, but the dot itself hasn't a special meaning. It was only there to make it more readable.

    And don't get me wrong: I don't want to say that the dot notation is senseless and the additional readability isn't very much. I only wanted to say, that maybe it could be useful, if the asterisk get a special meaning.

    But they don't need to implement a special meaning for the period, as this is simply a character in the name. It is simply, why do you need a special meaning for the period. It is there only for readability and don't change the behavior of the permissions. “star.gate.open” and “stargate.open” are only different “branches” because the name is different. “foo bar snafu” and “foobar snafu” are also different branches without any period ;)

    Ehm, I only wanted to say, that also with the old system it is possible to define a permission node “fred of the jungle$$123”.

    Fabian
     
  17. Offline

    Flenix

    Hmm, I got a question that wasn't really made clear:

    If I update to CB1000, can I still use the permissions plugin and ignore the built in permissions? I updated to permissions 3.1.6 recently and it works really well... we have about 35 different groups and a huge users file too sorting all our users to various groups and multigroups.. I REALLY don't want to have to change all that to a new system if I can help it...

    Until I know I can keep the old Permissions plugin I think I'll stick with 953, as buggy as it may be...
     
  18. Offline

    ToastedJelly

    Another question... if the user gets assigned doorman.*, can I ask if he has doorman.*?
    If this works, can I also ask fro doorman.* if I assign kick,ban,knock separately?

    doorman.*: description: Gives access to all doorman commands children: doorman.kick: true doorman.ban: true doorman.knock: true


    You can keep your permissions as long as a dev updates it to work on the build you're using. It will take quite some time till permissions plugin use this new system and then it will be marked so.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 17, 2016
  19. Offline

    4am


    Groups will be handled by plugins if you need them. Bukkit isn't providing a complehensive permissions management system like you're used to withthe plugins - it's more like what Register does for economy plugins - it's just a common interface.

    You can define simple permissions in your server's permissions.yml if you only need simple stuff - perhaps you only use op/not op. Who needs groups if you have 5 users on a private server? This is meant to keep it simple for those who don't need Enterprise-level permissions.

    For those of us who DO want groups, wildcards, promotions, in-game commands, etc. these will be provided by plugins. Basically, Permissions "4.0" will, instead of having plugins hook into it's own interfaces, itself hook into Bukkit and report the permissions users should have (based on their group, etc). Then, plugins can hook into Bukkit's interface and check if expected nodes are set.

    This way, permissions are extensible as well. Want WorldGuard to change users' permissions when they enter a specific zone? Just config it. WorldGuard doesn't have to know what plugin you use for Permissions management (or if you don't use one at all!); it just knows the Bukkit interface. Don't like Permissions way of doing things? Maybe someone will resurrect GroupManager. Maybe someone will make an entirely new system. Hell, you could even have nodes defined in your permissions.yml based on classes in an RPG plugin like Heroes (each level-up auto-promotes you to the next node) and based on that your users automatically get access to more features/commands.

    Don't close your mind to this because Bukkit isn't going to manage your groups for you. Bukkit is doing what it was always designed to do, which is be as minimal an interface as possible and then GTFO of the way and let the community write plugins to handle the logistics how they want them handled. They're just providing a standardized framework here to ensure compatibility.
     
  20. Offline

    Techykid3

    I have a couple questions:

    1. are we still able to use rcjrrjcr's permissions plugin? Or did it break it?


    2. If i did switch over to this, will it break all the permissions-supporting plugins, until they update?

    3. Does this support chat prefixes and suffixes / colors, or will I still use iChat, or does this simply just not going to work out with this.
     
  21. Offline

    4am

    [citation needed]
     
  22. Offline

    Dinnerbone Bukkit Team Member

    You have to remove the permissions if they're going from one world to another, and such. Other permission systems have to do this anyway, it doesn't magically update itself. There is no extra performance cost.

    Groups don't exist here. You can use this system without groups, they're only for servers who need more than "player" and "op". Wildcard permissions were a bad attempt at a fix to a problem which doesn't exist in this system. So no wildcards.

    No, it just adds whatever permissions has been specified, bukkit does the rest.

    Don't cache the result. Bukkit does it.

    It supports any type of permission criteria, unlike any other system. Permissions only on one world? Easy. Permissions only in one chunk? Simples. Permissions only for 30 seconds after teleporting from a specific area? One liner.
     
  23. Offline

    4am

    rcjrrjcr's Permissions is not broken and will continue to function. In fact, currently it is necessary until individual plugin authors convert their plugins over to Bukkit's API. Read some of my above posts as to why this is a Good Thing™.

    rcjrrcjr's Permissions will (if he chooses) continue to exist as a system to manage permissions for users; Bukkit has only taken over the function of allowing plugins to get/set permission nodes themselves. (Permissions would do lots of setting of nodes based on assigned groups, in-game commands, etc. while other plugins would usually do lots of getting of nodes to determine if users had permissions to do specific things).

    Prefix and Suffix (among other variables) are not supported in their current form - that is really more of a config issue anyway. Chat plugins will need to allow configuration of the prefixes and suffixes in their own config files (perhaps checking for a permission node you define in your permissions.yml and specify to the chat plugin in the config file).

    In other words - the only big change this brings about is how you configure things. In the end, you're not losing any functionality, you're actually gaining quite a bit more.

    Let me make sure I'm understanding this correctly; once I create "myplugin.*", either runtime or in plugin.yml (not bukkit.yml, right?), I can't add or remove children from it (those children must be known at the time permissions are loaded) and I cannot delete it (in order to reinstantiate it with modified children). Is this correct?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 17, 2016
  24. Offline

    Dinnerbone Bukkit Team Member

    Correct. If you find yourself dynamically adding lots of permissions which you need to add to .*, consider just making .* an override for them (check .*, then check .x)
     
  25. Offline

    Celtic Minstrel

    You could stick with Group Manager, but I wouldn't recommend it unless someone has picked it up and is continuing to develop it. You don't have to switch to SpaceManiac's plugin if you don't want to; you can use whatever permissions plugin you want as long as it (eventually) supports built-in Bukkit superperms.

    It does seem counter-intuitive at first glance, but note that doorman.denied is actually intended as an inverse permission. That is, instead of giving you permission to do something, it revoke the ability to do so. So, with that in mind, excluding it from doorman.* (and, indeed, explicitly setting it to false in such) makes sense.

    This is up to worldguard to define. If I were the developer of WorldGuard, I would probably try to define it so that you can use the internal asterisk like that. I don't really know what WorldGuard flags are, though, so I'm not sure if that would be possible. It certainly wouldn't be possible in the plugin.yml; he'd have to define it programmatically upon loading.

    @SpaceManiac – Correct me if I'm wrong, but... I think you only need to specify the permissions that are not the same in every world under the worlds heading. So, in your posted example, you don't actually need a worlds heading because they're all the same, but if (for example) you wanted them to only have lwc.blockinventory in the creative world and not in any other, you could do something like this:

    Code:
        Guest:
            permissions:
                permissions.build: false
                essentials.geoip: true
                essentials.rules: true
                essentials.spawn: true
                lwc.blockinventory: false
                essentials.motd: true
            worlds:
                creative:
                    lwc.blockinventory: true
    
    While having a flush command is a nice idea, I think it'd be better as an API call than a default command.

    Not if the plugin author did it correctly. I have a permission that has one sub-node for every item. When the plugin is loaded, I loop through all the values of the Material class and add the corresponding permission to the .* permission. This way, if new blocks or items are added, it will automatically expand to include them as soon as Bukkit adds them to the Material enum (which I think is one of the first things they do after updating anyway). You don't want to define permissions like this in your plugin.yml; that would just be insane.

    That's true, it is possible with the old system.

    There should be no problem with sticking to Permissions. Presumably it'll eventually be updated so that it works with plugins that rely on Bukkit's permissions system, but even before it does that there's no reason why it shouldn't continue to work with plugins that explicitly support it.
     
  26. Offline

    BattleGroundxx

    Hey Dinner bone can you explain to me this: do we still need a permissions plugin?
    And can you help me write the code for the permissions.yml?
    Basically I am the server owner so naturally I'm the admin and have access to all commands my minecraft name is: BattleGroundxx
    And my friend is part of another group (moderator) and has access to all default commands (build, destroy etc.) His minecraft name is: mittydoug
    And i know that certain plugins have permissions and since this is a private server the admin and moderator groups have access to all commands that are required by plugins
    and i am going to install
    PermissionsBukkit v1.0 - Official Default Groups Plugin [1000]

    So all I ask is you write the code for the permissions.yml and the plugin above because im not so computer savy and 1 more thing the moderator group does not have access to these commands (basically the ones required by PermissionsBukkit) anyways these are the command the moderator group has no access to:

    PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

    /permissions reload - reload the configuration from disk.
    /permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
    /permissions info <node> - prints information on a specific permission.
    /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
    /permissions group - list group-related commands.
    /permissions group list - list all groups.
    /permissions group players <group> - list players in a group.
    /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
    /permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
    /permissions player - list player-related commands.
    /permissions player groups <player> - list groups a player is in.
    /permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
    /permissions player addgroup <player> <group> - add a player to a group.
    /permissions player removegroup <player> <group> - remove a player from a group.
    /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
    /permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

    If you can do all this i would VERY VERY VERY VERY much appreciate it!

    The plugins I am currently running are:
    AutoRepair
    BananaChunk
    ChopTree
    ClayGen
    FastObby
    HeroicDeath
    HomeSweetHome
    IntelliDoors
    ObsidianFlow
    SpongeRestore
    Stackable
    Stargate
    TorchLight

    Again all groups/users have access to the commands required by plugins!
    Thank you very much if you can write the code for permissions.yml and the PermissionsBukkit That would be so helpful I know this is a Large request but again I am not computer savy with java. If you can complete this for me I that would be greatly appreciated.

    Thank You!
     
  27. Offline

    4am

    That long list of commands you posted - that's for setting the permissions yourself. You don't need to touch a config file. You just need to know what nodes the plugins use. Also - none of those plugins recognize the new Bukkit system yet (they need to be updated to use it). Keep using your normal permissions system for now - Dinnerbone probably does not have time to go around writing config files for everyone.
     
  28. Offline

    dwdminecracked

    That actually makes some sense to me, thank you that help alot XD
     
  29. I have to ask, what was this problem and in what specific way where wildcards such as worldedit.* a bad attempt at a fix for it?
     
  30. Offline

    Dinnerbone Bukkit Team Member

    The original problem was, "how do people give all these permissions that they should already have", like giving all the hundreds of op related commands to ops. .* was a bad fix, because it just flat out says "you have these commands" and completely screws up when it comes to negate permissions (permissions that you want to be true to deny access to something).

    With this system, none of these issues exist. You actually only have to give op related permissions to groups that you want to be "like op" but not actually ops, because of the defaults. You also have more freedom now with giving permissions out, depending on the plugin developers will. You can easily just give "someplugin.moderator" to a person which includes all moderator commands but not admin ones, and then customise that later if it doesn't include some others that you wanted. Much more flexible.
     
Thread Status:
Not open for further replies.

Share This Page