Issues with Bukkit Permissions (aka "SuperPerms")

Discussion in 'Plugin Development' started by cereal, Jul 17, 2011.

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


    First of all, congratulations to the Bukkit crew with their 1000th build. I am glad to have used Bukkit and also wrote plugins for as well. However, I am a bit flustered and frustrated over the recent inclusion of Permissions as an API within Bukkit. I am posting this so others can understand my view point. I'm not interested in an argument. Here are the main reasons:
    • Groups
    • Option Nodes
    • Persistence
    Using groups is incredibly useful as we check (for LocalShops) if a user is within a list of groups to restrict access to a shop. The groups are configured in game by a command issued by the players. My problem is in the line that groups provide an amazingly flexible avenue for heirarchy, bundling, and convenience.

    Considering a node as a replacement just simply doesn't provide enough. For example, let us assume we have a group named "admin", what node should I check of the following? "admin", "group.admin", the possibilities are endless and groups become meaningless between plugins as devs define them differently. More importantly, a node doesn't provide ability to group permissions together.

    Option Nodes
    Option nodes provide the ability to store a parameter (String, Integer, Boolean, etc) along with a node. This allows the ability to provide additional customization of plugins. So why is this such a disappointment? Imagine being able to set limits on the number of times someone can use a command or how often someone can chat or the number of chests someone can protect.

    With option nodes we can simply define a key and obtain a value. Many plugin developers know and understand the value that Maps give us these days, this is literally what Option Nodes provide us. Imagine the insanity of checking all permissions on "myplugin.mynode.100" through "myplugin.mynode.0" or whatever your values are instead of simply providing a map.

    Option Nodes can provide limitations and work exceptionally well as a permission based system (while some plugins do not use it this way, some do).

    I am personally baffled that Permissions are not persistent in Bukkit. Why would they simply not be persistent? What value does it bring to require an additional plugin thats sole purpose is to provide persistence? Seems that instead of downloading Permission plugins we will not see the cluster of "Permission Persistence" plugins and that completely defeats any plausible points of integrating Permissions into Bukkit.

    I can understand if built in Permissions provides a simpler avenue for some plugin developers and I personally am glad for such a system. However it lacks features that ALL permission plugins have in common these days and more importantly, it does not simplify the use of Bukkit for server operators. I believe it only adds yet another system to code for instead of replacing the need for Permission plugins altogether.

    These are just my thoughts and I'm sure others also have their own. Again, I'm not interested in arguments and simply wanted to share my opinions.
  2. Offline


    I think this is the main reason why I don't see it as an actual benefit. While bukkit may have increased it's flexibility in regards to plugin development and attempting to set a standard for permissions, I feel like it is inadequate, and doesn't improve anything at the server operation leve. A server operator still has no built-in permissions and must go seek out a permission 'persistence' plugin to fill that void. As a server operator I don't see any benefit in switching to bukkit's builtin permission system because of the limitations listed above. While it is a step, and this is just my observation, it feels like the choice to not provide persistence was a very serious error. I thought the whole point of providing a builtin permission system was Primarily to simplify the setup process for server operators and Secondarily to provide developers an easier method to access those permissions. It seems like the secondary reason has become the more focused one in this case, and this doesn't feel like a good move on bukkits part.

    tldr; It seems like nothing has really changed. You still have to have a persistence plugin for persisting and registering a plugin's permission, so on the server level there is literally just another choice as to what that permission provider is.
  3. Offline


    I could go into an in depth analysis of your post, and give a long post about my own opinions, but for now?
    I'll stick with this:

    My Opinions (open)

    You're right. I dislike them as well.
  4. Offline


    Well, actually permissions can have child permissions, but yes, I do agree with your point that there are situations in which a plugin will want to obtain whether permissions are to be considered "groups," and the current system does not provide any method for this.

    I feel like the Bukkit crew (but of course, cannot speak for them, and was not there when they made their decisions) may have been trying to intentionally not copy Permissions or other existing permission handling plugins and instead provide a very generic, central and convenient hub for other plugins to build on. In the end, though, with the current format, it simply cannot be simultaneously central and convenient because other plugins will have to build up on it from very bare foundations to such a level that they will all work differently (which, therefore, makes it non-central and difficult to discern distinct patterns between permissions setups per plugin per server).

    At the current state of features that Bukkit provides, I'd rather just work with Permissions. The Bukkit permissions system does not provide enough of the needed features to stand up on its own. Instead, it adds another layer through which permissions systems must dig to find intent of server owners. If no permissions plugins existed, this would be a fantastic upgrade. However, comprehensive permission plugins are already a huge part of the plugin system, and by effectively endorsing the use of one permission management method (i.e., the Bukkit permissions system) plugin developers simply have to add more code to support more things.

    Still, with the necessary tweaks (add group structure, allow the possibility for it to stand alone but still allow plugins to build on it) it could be a nice addition to the Bukkit system.
    Sleaker likes this.
  5. Offline


    Everything i wanted to say were said before me by this good people :)

    I think current superms should be redesigned considering demands of plugin developers and server administrators, not just thoughts and willings of several man.
    Roadkill909 likes this.
  6. Offline


    I'm willing to play devil's advocate.

    I like them. While the implementation may not seem to be super effective, after having designed a simple plugin with the new permissions system (that basically defines nodes for each of the basic server commands, being /give, /time, etc), I didn't have to think at all. The permissions system just works, and it does so in a very straightforward manner.

    It requires a little bit more thought (and perhaps some more time) on the part of the developer. Learning how to configure PermissionsBukkit (SpaceManiac's implementation of bukkit's new permissions) took all of 5 minutes, and after that I had created multiple groups with different permission nodes, all with a very logical and clean layout in the config.yml.

    I understand the primary complaint among server owners is the lack of an info field, but this is easily remedied by the plugin developers who utilize this information persisting their data on their own for their own plugin. The only situation where I can see this being less than optimal is in the case of Localizations, which many plugin's don't really use or need.

    As for prefix and suffix, this information is sort of ignored by permissions and used by other plugins (iChat, HeroChat), for reasons that I can't and probably never will figure out. This information belongs in the configurations of the plugins that need them.

    Anyway, I'm enjoying them, I'm supporting them. I probably won't use any other permissions systems, and will rely on server owners to use the SuperPerms bridge or something to interact between my plugin and legacy permissions. I just can't figure out why this is "such a bad idea."
  7. Offline


    Do you realize what having complete user/group hierarchy for each plugin is complete mess?
    For example you have 1000 registered users, now image server administrator pain to enter this settings for each plugin - RPG/Chat/etc.
  8. Offline


    That's just it though, You are only taking it from a developer point of view. In comparison setting up a base permission on a server is #1 more flexible and #2 easier than even dabbling or attempting to dabble with BukkitPerms at all. So the only end gain is the possibility of easier developer access, the thing is. I've been running my own permission/econ hooker for a while now so pulling a permission is easier for me than touching BukkitPerms. I run 1 method just like Bukkit - but I have complete control over what those methods are called, and how they call the different permissions API. In addition it wasn't that difficult to setup, nor did it take very long. Supporting multiple permissions systems is usually a matter of a couple switch statements and a couple method calls, But if I already have a base class it's not hard to just drop this into every plugin, or even use it as a standalone.

    As t3hk0d3 mentioned the prefix/suffix/option node thing is not limited to iChat/HeroChat. It means any plugin that wants to provide an externalized option based on a permission entity (group/user) will now be required to #1 maintain it's own list of options, and #2 provide it's own API hooks for them. This does not make developing for these any easier, and it also makes it more difficult for server operators to keep things current.

    You may think that it's a good idea for a server operator to have to change a prefix or option in every single plugin that wants to use it now, but I don't see it as a good thing. If I want a standardized list of them I want to change it in 1 location and be done with it. Not change it in every plugin that needs to use that 1 variable.
  9. Offline


    As it is I won't be supporting the "superperms" system, it lacks features, removes things that almost every server uses, and is in general a step backwards. I recommend other devs follow suit, stick with Permissions.

    [Edit] Just to clarify, stick with Permissions 2.x ;)
    Jobsti, Elizacat and phaed like this.
  10. Offline

    Celtic Minstrel

    Not true, since a permission can have children.

    It's not really the responsibility of the server operator to switch to Bukkit's builtin permission system. It's solely the responsibility of the plugin developers. The server operator can just go on as they are now, blissfully unaware of the change, as long as all their plugins properly support the Bukkit permissions.
    This possibility already exists, because it lets you set defaults. Obviously that's not the same as having a built-in group system, but if you're satisfied with just two groups (op and non-op), then it's quite sufficient and, thanks to permissions.yml, even customizable.

    Boolean options don't really fit this picture, since they can be easily transformed into a regular permission node. I can't think of a string option that really needs to be inherited, since any string option I can think of would be different for every group. Numeric options I can understand, though. This is one minor shortcoming of the Bukkit permissions system. However, it's not insurmountable. For starters, why would you have to check all of "myplugin.mynode.100" through "myplugin.mynode.0"? Just check the permission for whatever number is actually applicable; for example, if it's a limit on the number of times someone can use a command, you keep track of how many times they've used it, right? Then, suppose this is the tenth time they've used it; you check "myplugin.mynode.10". Of course, this means you need to build a permissions hierarchy where "myplugin.mynode.<x>" contains "myplugin.mynode.<x-1>" as a child permission, but that's easily done in perhaps five lines of code with a for-loop. Still, I agree it's not the best method of doing this.

    Did you release it? Can I see it? Because, I made a plugin to do the exact same thing (except I was linking with Permissions).

    Um... where on earth did you get this from? You don't have a separate hierarchy for each plugin. You have a groups plugin that manages the hierarchy, and you input the groups and users just once in that plugin's configuration file(s).

    For the prefixes, how many plugins actually use them? Chat plugins, obviously. That's all, right? For variables, how many variables would be used by multiple plugins? Very few, I should think. Still, if you're in an unusual situation where you do need several plugins to access the same inherited variables or the prefixes, then there's nothing to stop you from using a groups plugin that supports that sort of thing. Since Bukkit doesn't have groups, there isn't really room for inherited options; thus, they need to be handled by the plugins provided groups instead. Yes, it does mean that if you need these things you'll still need to build against a selection of groups plugins, but I think most people will find that they don't need them.

    Seriously? You want me to continue to build against plugins providing permissions when Bukkit itself already does this? No chance; I intend to switch over to Bukkit permissions entirely, and drop official support for any permissions plugin. Naturally, this means the permissions plugins will need to hook into Bukkit's if they want to survive. I don't see anything difficult about that, though, unless they want to emulate the old meaning of wildcards.
  11. Offline


    so then whats different than before?
    1. we still need a plugin
    2. we have less options with bukkit.perms
    3. we still need to hook into another plugins api to get back missing features in bukkit or fiddle strange workarounds with nodes to simulate old behaviour
    4. we have another peace of dead code aka bukkit.perms api in bukkit
    5. bukkit.perms is just the man in the middle, not a very good one, all the other plugins were backwards compatible to old permissions 2.x, so there already were an api that is unified why reinvent the wheel?

    bukkit.perms had as first aim to end different apis of permissions, to unify this, to make a standardized fullfeatured permissions api: mission failed.

    you say you will support only superperms of bukkit, i respect this. you may be right that other permission plugins will die, but i am not very sure in this point. most probably they will survive because of plugin developpers who will support them, and if some plugins wont they will be forked and ported or there will be made alternatives. so if you dont support also your plugin could die or loose popularity.

    another reason why the mission is failed, you see, instead of unify the plugin devs it splitted them into two sectors, those who love and those who hate it :)

    i think its not the end of storry, i think bukkit permissions will be improved by time. dont get me wrong that i just hate them, i hope for more, with reason.

    there were a lot of work already done in permissions branch of bukkit, that was more similiar to the old style permissions. where is it gone? why bukkit.perms looks like something that was hacked together in few minutes?

    i dont want to sound offensive in any way, i just cant express my feelings in english very well. and Celtic Minstrel, i quoted you just because your words triggered me to post here my thoughts. its nothing against your post :)
  12. Offline


    I have not released it, I did it for my own server and just as a way of getting acclimated with the new permissions.

    I'll PM you a snippet.
  13. Offline

    Celtic Minstrel

    For server administrators, (almost) nothing. For plugin developers, you no longer need to hook into some other plugin's API to get permissions. Yes, you may need to hook into another plugin's API for some of the missing features, but most of those features either are not needed by the majority of plugins, or could be done in a different way to avoid the need of hooking into some plugin's API.

    If you want groups, then yes. If all you want is permissions, you don't need a plugin.

    Less options? How so?

    I don't really see this as a problem, since those missing features are not permissions and are not needed by most plugins that use permissions; they're just things that the existing permissions plugins happen to include. As for workarounds... if you mean defining the wildcards manually, then yes, that's a little painful.

    Calling it dead is a bit of a stretch if you ask me.

    It's not a case of reinventing the wheel so much as improving on it. I won't deny that there are also some downsides to the improvements, such as the removal of wildcards, but on the whole I think it's better then the existing Permissions 2.x. Besides, thanks to SpaceManiac, even superperms is backwards compatible to Permissions 2.x.

    How did it fail? It's a (fairly) full featured permissions API; sure, it might not support groups, but groups and permissions are two separate things. The only thing I kinda wish it had is integer permissions.

    I don't think other permissions plugins will die; I think they'll start hooking into Bukkit to set their permissions rather than just providing a public API of their own. Thus, plugin developers will only need to support Bukkit superperms, and by doing so they'll support every groups plugin as well.

    True, that's a bit of a problem. I hope people will use it even thought they dislike it, though; maybe it'll even be improved further in the future. (As you even said yourself.)

    I think they stopped work on that because people were complaining it didn't give enough freedom to plugin developers to define their groups in their own way, or something. I don't quite remember the details, but basically it was less flexible in some way.

    Fair enough. :)
  14. Offline



    While I understand some people prefer ease of use and simplistic permissions (has(permission)) and that they don't really mind having fewer features. However, when someone currently uses them it really throws a wrench in your plans and it does bother me that they don't exist to a great extent.

    Any API that is meant to unify permissions should support features that are common across most of the permissions systems and really, a server administrator must not need to supplement Permissions with Persistence and Group plugins (or even worse two separate plugins to do each one individually). While this unifies the most simplistic form of Permissions, it further complicates plugins that have been using these features for little to no benefit of the developer or user. I know that my plugins have gained quite a bit of functionality and usability by using these advanced features.

    I also understand that nodes can be grouped within other nodes, but at this point why not just make groups and simplify the usage of them? The lack of structure for groups (as in, they don't really exist except that you can work around it and use a node) really just makes this all much more complicated than it should and the lack of a * permission node really hurts administrators.

    Please understand that not every plugin is the same and the requirements for each will be significantly different. With that said, these advanced features that seem unnecessary to some are quite mandatory. I know that some features in my plugins will simply either cease to exist or they'll get complicated quickly for the user if I move to SuperPerms, which I'd prefer to not do if it results in either outcome.

    I personally am hoping for a stronger unified Permissions framework, but this is too little to support my development needs at this time (see my original post pointing out the 3 major issues I have). If a user is required to download a plugin to finish a built in system, the it isn't enough, it isn't complete and if I can't simply stop using current Permission systems, then it also isn't complete. Unfortunately, both issues are prevalent in the current system and I simply cannot move to it.
  15. Offline

    Celtic Minstrel

    It seems we disagree on a basic point of design philosophy. I personally would prefer to have separate plugins for Groups, Persistence, and Permissions. (And of course, now that both Permissions and Persistence are in Bukkit core, that's two less plugins needed!) I'd rather have several plugins that have a narrower focus but do their job well than have one monolothic plugin that tries to do everything but (as like as not) doesn't do a good job. (Though, my General plugin may be doing a bad job of maintaining that sort of state. <_< )

    The lack of .* style nodes won't really hurt administrators as long as plugins provide an alternative (or simply define the .* style nodes as a separate node with children), and the lack of a * will actually help administrators in some situations since they'll need to actually think a bit more about what permissions they're giving out and whether they really want to give out a certain permission, for example a permission that automatically enables god mode when you log in.

    I'm not saying that the advanced features are unnecessary overall. They are however not necessary to many plugins, and by having permissions within Bukkit, those plugins that don't need the advanced features will no longer need to build against a permissions plugin. Some that require advanced features may still need to do so, but I think they're probably in the minority.

    The user is not required to download a plugin to finish Bukkit permissions. Bukkit permissions are pretty complete. Yes, they don't have groups, but groups are a separate entity that some servers don't even need, and with Bukkit permissions those servers can do away with any permissions plugin.
  16. Offline


    We clearly do not agree. My opinion is that a server administrator should not need to include ANY plugins for Bukkit core API's especially for Permissions. I can't imagine the number of questions about why servers keep loosing their configuration on restarts. Additionally, while the permissions work for you, they are a complete fail and I cannot use them which just makes this more confusing for users.

    My biggest issue is that this is not a unifying effort, its simply another branch that developers have to choose to use or not.
  17. Offline

    Celtic Minstrel

    They don't have to. You can use Bukkit permissions without any supporting plugin, with just the two basic "groups" of ops and non-ops. You only need to include a groups plugin if you want the extra diversity it allows. For very small servers, groups are not needed at all, so why should the server administrator be forced to include a plugin that gives both groups and permissions when all they want are permissions?
  18. Offline


    Except they aren't persistent across loads from what I've seen, there's no way to modify users permissions without a secondary plugin, no notion of groups. It's nowhere NEAR complete.

    So server owners are now completely dependant on plugin devs having the same idea of defaults as them, or they're required to have a separate plugin. Sounds exactly like the existing system if you ask me.
  19. Offline

    Celtic Minstrel

    Permissions without a groups plugin are persistent across loads, since they would be defined either by the plugin itself or by the server administrator in the permissions.yml file. A notion of groups beyond ops and non-ops is not needed for some smaller servers.
  20. Offline


    If I may be so bold, are there any plugins yet that provide groups (and integrate permissions into the groups) and * permissions? If not, all this talk about the mythical plugins that can do this is just plain nonsense. The functionality is gone now, and without a replacement, I don't think I can use superperms in good conscience.
    cereal and gsand like this.
  21. Offline

    Celtic Minstrel

    There's bPermissions and PermissionsEX which might emulate wildcards; I haven't looked into them myself so I could be mistaken.
  22. Offline


    Then isn't Player.isOp() what you think small servers need and that's all? I still disagree and have no desire to re-write my plugin because super perms isn't up to par with the feature set that I prefer and provides significant issues for larger servers. I can't alienate the large servers because Groups (or any of the other options that were missing) are too difficult to understand.

    Agreed. Even with multiple group plugins being available, the pain of Permissions is lessened not one bit for those who require groups. Plugins will just have different dependencies and server admins will be just as confused.

    As I see it, Bukkit Perms / SuperPerms was a solution to provide another Permissions system that solves the entire mythical problem surrounding developers and admins alike and really, the XKCD comic #927 sums the result of said effort perfectly (as in, it didn't help one bit).
    Elizacat likes this.
  23. Offline


    Just spent today making a small MySQL based Permissions manager for a server I help with, my solution to this mess? Just coded for Permissions, and superperm, I admit I would much prefer it if they had added some more work into this, it is a step in the right direction, but they seemed to ignore the fact that permission manager do NOT just handle a list of permissions now, they handle groups and the info related.
  24. Offline


    How do you handle groups and other missing features in superperm that are available in Permissions?
  25. Offline


    When my code is registering a player, it gets a list of all permisisons that player has access to, and adds them, it goes form base parent up the tree to the player, so like if it finds testperm.* it will not try and add testperm.test later. For actually finding the group etc? it also has a bridge plugin that pretends to be permissions 3.0 so it is compatible with both. is a work around yes >.< I agree groups and info should have been added.
  26. Offline


    That makes it hard to implement groups in plugins. Using groups was a great way to restrict access. For LocalShops we added user and group lists per shop that would restrict to those users and groups if defined which really simplified it for larger servers. Especially now that there are so many RPG based servers, groups tend to be necessary minimally for them.

    I'm sad to see one plugin get split into many. Permissions is now Permission Handler, Groups, and possibly even a Permissions Bridge as well. This isn't ideal.
  27. Offline


    Hence why I made a bridge from my plugin to permissions, so any that tries to use permissions to get groups would work with it
    My small permissions manager has groups, group data, and user data. It can only expose the permissions themselves through to superperms, but it exposes the rest through a permissions plugin bridge hence why I KEEP agreeing that this is not ideal.
  28. Offline


    I am all for a built in permissions - but it must be the full package or it will only divide the community further.

    Had something like this came out 5 months ago, I wouldnt have even worried about any other temp Perms system we were using and switched over.
    I believe in this community and I know the best possible Perms system will be built in.
    cereal likes this.
  29. Offline


    I think part of the problem here is the name, a permissions system is simply that permissions, what we need more is user management.
    cereal likes this.
  30. Offline

    Celtic Minstrel

    Player.isOp() is all that sufficiently small servers need. In a way, it's Bukkit's built-in group system, with two groups: ops, and non-ops. If two groups is all you need, and all your ops are trusted enough not to do something stupid with the vanilla commands that the position gives access to, then there is no need for any expanded groups plugin. Of course, you could have a small server for which isOp() isn't sufficient. The point is that there will exist servers that need permissions but do not need groups.
Thread Status:
Not open for further replies.

Share This Page