Permissions - Where We Are Today

Discussion in 'Bukkit Discussion' started by obscurehero, Jul 21, 2011.

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


    I'm reposting something I read in the PermissionsBukkit thread that was incredibly helpful to me! In my honest opinion (IMHO), I believe this should be something that is easily accessed. For those of us with limited experience/time, its very hard to dig up any kind of definitive word on what the current state of affairs is.

    Without further ado:

    Another post in this thread:
    This, of course, isn't the final word, but at least a starting point for discussion. I'd love to hear what plugin dev's think of this and what directions they plan on going with their own plugin development.

    This (bukkit), of course, is a work in progress. Its hard enough to write the code, de-bug it, and keep it up-to-date with bukkit/MC. Let alone trying to run PR for your plugin, but we really appreciate the effort!

    @Jeyge - The PR god for the Permissions Team (@rcjrrjcr @TheYeti @Nijikokun) had this to say to a recent query:

    For the server admins:

    What kind of signals/milestones are you waiting for before you migrate to a plugin utilizing SuperPerms?

    For your reference:

    Permissions plugins that utilize SuperPerms (Bukkit native permissions):
    (SuperPerms) Permissions FAQ
  2. Offline


    I hope someone will post a video soon that explains Superperms.
  3. Offline


  4. Offline


    Hmmm... I don't know.... :O
    Maybe i'll add optional superperms support *IF* there is no permissions plugin? I don't really get superperms though :/
  5. Offline


    I added support for the new SuperPerms system to my plugin, but still give the option to instead use the "classic" Permissions system. In the long run (next few weeks) I'll drop support for the "classic" Permissions system, because the new system is simpler and faster (no joke, with some of the old Permissions-plugins executing a simple "permissions.hasPermission(player, "some.thing") took twice as long as the actual calculations done by my plugin, which makes a big difference if you have to handle high frequency events like onPlayerMove).

    Until then I expect all people to switch to a newer SuperPerm based Permissions-plugin and/or the old Permissions-plugins to support the new SuperPerms.
  6. Offline


    I would hope that if this is the tack that plugin developers take, we'll hopefully have something like superpermsbridge to retain 'legacy' support. As a somewhat novice server admin, I will admit I am not eager to embrace any impetus to change. The whole 'if it ain't broke' thought process...

    I really appreciate the candid thoughts! Very helpful to know what plugin devs plan on doing!! Keep the discussion going!
  7. Offline


    This is my plan as well. I'd love to just completely drop 'classic' Permissions right away, but people would kill me. There would be wailing and gnashing of teeth. I am a bit concerned about this though:
    This seems backwards. The permissions plugins should begin to support the new system first, so that the other plugin developers can safely convert to the new system without making all of their users angry with them.
  8. Offline


    Except that the changes you make to your plugin.yml wouldn't hurt your users at all but would allow anyone using a permissions plugin to still be able to use magicspells.*. Without those changes, the wildcard permissions may or may not work.

    Edit - and supporting multiple calls to hasPermission for a little while shouldn't hurt anyone at all.
  9. Offline


    I just setup permissionsex and created a mysql database of many apps and ranks. I also maintained a ranked wiki reflecting all of these commands. So yeah I'll be really irritated if major plugin developers of things like NoCheat start removing classic permissions support right away forcing me to learn yet another permissions system and rewriting my wiki for the third time in 2 months.
  10. Offline

    Lunar Delta

    That seems like a very poor attitude to take. A great many people and their servers rely on your plugin to prevent undesirable activity, and not all of us are going to feel comfortable immediately switching to a poorly thought out and implemented permissions system that doesn't even offer a quarter of the ease or features of the current ones. And even if that wasn't the case, it is still going to be quite a while before all 50+ plugins I use on my server are switched over to the new system, which means in the meantime, all of the plugins that are coded by activist developers who want to push change through immediately will simply be unusable.

    As for the OP's question to admins, every single thing I have seen and read about Bukkit Perms has left a very poor taste in my mouth; I don't plan on switching until a time comes when I literally have no choice.
    bmxrcodol04 and HmmmQuestionMark like this.
  11. That is exactly how I feel.
  12. Offline


    There seems to be a lot of misunderstanding about the new permissions system. It isn't supposed to have all of the features of the old plugins. The idea is that your preferred permissions plugin can utilize the new system, while still maintaining all of the features it always had. You can still use your preferred permissions plugin with the new system. Once those plugins have updated to support the new system, any plugins, whether they use the "old" way or the "new" way, can peacefully coexist side by side, because the permissions plugin can still support both at once.
  13. Offline

    Lunar Delta

    I understand all of that, but here is the problem. I use GroupManager. GM will almost certainly not be updated to support superperms. This by itself wouldn't be an issue, if it weren't for the fact that a lot of plugin devs seem to be eager to drop support for old permissions systems at the soonest possible moment. This means I will not be able to use the latest versions of those plugins, missing out on bugfixes and new features. Which means I will have to simply leave my server in a state of permanent stasis.

    Or, I could update to one of the plugins that uses superperms. But this means that all of my older, inactive (but otherwise fully functional) plugins will cease to function properly. I have several plugins like this that for various reasons I literally cannot afford to have stop working. It would also mean completely rebuilding many things from the ground up, like user lists, groups and per-group permissions, peoples' prefixes and suffixes, among other things, which will be a monumental PIA.

    Even if the plugin supports both older and newer permissions, there is a chance that these plugins still will not be compatible with it. For example, the reason I have not updated to Permissions 3 (other than it being a terrible mess) is because many of my plugins simply fail to work with it, and chances are they never will. So even if P3 ended up supporting both systems, I would still be in the position of losing several of my best and most important plugins.

    No matter what I do, it is only a matter of time before I am in a load of trouble, and I am none too pleased about it.
  14. Offline


    My plugins first attempt to use PermissionsEx, then attempt to use Permissions, then failing that, use Bukkit Permissions.

    Once PermissionsEx supports Bukkit Permissions, I will remove specific utilization of PEX. Once Permissions supports Bukkit Permissions, I will remove specific utilization of Permissions.

    This to me is the best way to gracefully drop the old permissions plugins with fewest issues.
    HmmmQuestionMark likes this.
  15. Offline

    Lunar Delta

    This seems like a good idea. :)
  16. Offline


    As a plugin dev, I'm pretty confused about what I actually need to do to work with this new permissions system.

    Right now, I have 2 plugins, and they both use Permissions (never got round to adding support for other permissions plugins, though it's something I vaguely planned to do).

    But this new concept just isn't making any sense to me. I've read the FAQ and the discussion and it just left me feeling more confused.

    So what do I need to do? Is it:
    1. Adding permissions definitions to my plugin.yml
    2. Changing my plugin code to check for permissions... how? player.hasPermission() ? Should this be the only check I make, or should I keep my existing Permissions checking code and fall back to player.hasPermission() ?
    And as a server admin, what do I do? Granted it's only a little server and groups aren't too important, but what plugin am I supposed to use now, and how do I migrate to that from Permissions?

    Just seems like a real mess, and my inclination is just to pretend this whole new system doesn't exist and carry on as I am now :oops:
  17. Offline


    As a plugin developer, if you want to profit from the new system:

    1. Define permissions and default values in your plugin.yml
    2. Check permissions by calling player.hasPermission("some.thing") anywhere in your plugins code.

    That's it, no dependencies on other plugins or similar.

    If you want to support the old system too:

    3. Catch a reference "perms" to the "Permissions" class of the Permissions-plugin.
    4. Check permissions by calling perms.hasPermission(player, "some.thing") anywhere in your plugins code.
    5. Decide which answer gets precedence, if SuperPerms and "classic" perms contradict each other (or give the server admin an option to decide which system gets used)

    As a server admin, if you want to profit from the new system:

    1. Install a Permissions plugin that supports the new system
    2. Configure who gets which permission within the config files of that plugin

    If you want to support the old system too:

    3. Install a Permissions plugin that supports the old system (if you wait a bit, you may get one that supports old and new at the same time, so you don't have to use two different Permissions plugins at the same time)
    4. Configure who gets which permission within the config files of that plugin (same as above, waiting for one that supports both may be a good idea and save you that work)
    5. Keep your configuration files in sync (only if using two different plugins, obviously)
    (6. Change plugin configurations to exclusively support one of the two systems)

    EDIT: As you can see, it is perfectly possible to support both systems in parallel, but (of course) more work for server admins and plugin developers, plus it leads to problems if the servers permission configuration is ambigous for the two system.

    A final word: Don't use the "permissions.yml" that is in your Bukkit folder! It is NOT for giving permissions, it has a completely different purpose. Best you leave it blank unless you know what it does. Chances are you don't need it, ever.

    It is used to define permissions (like in the plugins.yml). You can e.g. define an "administrator" permission that has child permissions "someplugin.admin.something", "someotherplugin.admin.somethingdifferent" and then use your normal Permissions plugins to just give people the "administrator" permission, instead of all the seperate permissions.

    PS: "config files" may also be database entries or similar, depending on what Permissions plugin you use.
    desht likes this.
  18. Offline


    On the whole, terribly helpful! Thank you!

    As far as this last bit, I'm not sure that I agree. The permissions.yml is supposed to let you create perms for groups to reduce typing...and to allow you to use smaller perms plugins that might not support groups. In this way, you're creating pseudo-groups. I think, if I get it right, it is one of the few features I'm excited about. Especially considering they've done away with the * permission.

    As for the other comments, keep 'em coming. I'm glad to discover how the change is being perceived. I still think, for the most part, there is still a lot of confusion around the whole thing. The general mood still seems to be: "ignore it"

    While I can see it as a good change, I am not excited about the extra headaches that will go into the changeover.
  19. Offline


    If I understand it correctly, the pseudo-groups that you talk about are actually groupings of permissions. permissions.yml allows you to set up parent child relationships that aren't currently in the plugin.yml allowing you to keep your worldedit.*. Without that information in either permissions.yml or the plugins plugin.yml, you will need to define most permissions at the lowest level.
  20. Offline


    Exactly. I, for one, will miss the catch-all '*' permission as it allows full permissions without op privileges. Maybe this is the lazy way out, but it will also put the onus on plugin developers to fully annotate their permissions nodes on their wikis/post as well as in their plugin.yml and server admins to pay better attention the the nodes they grant.
  21. Offline


    Lazy way or not, it is the way most people have their permissions. As of right now with the way things are, every one of those people will have to use a hacked up permissions bridge that does some funky multi-node checking to make *, foo.*,*,*, ... work or define every single permission under *. I really don't see either as a viable option. Especially since the hacked up version of the bridge will stop to work once the plugin devs change their code to only call player.hasPermission().
  22. Offline


    I am already getting headaches.
  23. Offline



    This is getting incredibly confusing. So, you mean to say, unless it is defined somewhere that plugin.* has all of its children either in the plugin.yml or in the doesn't view it as a wildcard flag?
  24. Offline


    Yup. This is incredibly annoying and confusing.
  25. Offline


    I believe .* will sometimes work one level deep so as a bad example but one of my favorite plugins, you could use magiccarpet.* to work for and/or but it wouldn't work for (not a real permission). The plugin dev would need to define the following for it work as it has in the past:
      *: false
            default: op
            default: op*:
            default: op
    This would be in their plugin.yml or you would have to do the same in the permissions.yml file. Once that is there, then the magiccarpet.* will work correctly.
  26. Offline


    Yeah, after further reading, this is definitely the case. PermissionsBukkit has a decent system with its current superpermsbridge plugin and corresponding parent node for any current permissions 2.x and 3.x plugin. The bummer being, that you need to append this prefix to every existing node in your current configuration.
  27. Offline


    The proper way to handle this, though, is to put the defaults in the higher groups, not on each specific node.
  28. Offline


    I just stole the example that Dinnerbone posted and modified it for MagicCarpet. I'm pretty sure I broke it by removing the description but it wasn't meant to be used as the real changes that would be needed but instead as a sample of how to get your .* and .foo.* to work.
  29. Offline


    Thanks, that does clear things up a lot. I think the way forward for me will be to continue to support Permissions for now if the plugin is available, but if not, then I'll use player.hasPermission() instead of just checking for op/not-op. And I'll include a permissions: section in my plugin.yml.

    At a later date I can look at dropping Permissions entirely and just use player.hasPermission() for everything.

    Seem like a reasonable approach?
  30. Offline


    Am I wrong, but it doesn't seem terribly difficult to retain legacy support. I just don't like being strong-armed into making a switch when the most of my plugins don't yet support superperms.

    CreativeGates I just found out does this...frustrating!
Thread Status:
Not open for further replies.

Share This Page