Permissions FAQ

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

Thread Status:
Not open for further replies.
  1. The lack of dynamic permissions is really becoming a pain in the ass.
    A complete reload or even a reboot to add a permission node as a child. Yeah, makes perfect sense.
     
  2. Offline

    imjake9

    Ah, I see. So we need to stop thinking of permissions as things that server owners define and as what they really should be: what players have what abilities. Looking at it from another perspective makes things so much more versatile. Now, we can think of permissions not as a bunch of nodes in a text file, but instead an abstract list of temporarily stored player "properties". So, the plugin to assign permissions is only one way to give a player a permission. In fact, there are situations where the server owner might not even know a permission was being assigned! For instance, you might have a plugin that would give a user temporary flight powers (with a magic spell) by setting a permissions of "pluginname.fly", and that's all under-the-hood, not visible to users or admins. That means no need to keep long HashTables or other lists of players and their states on a plugin-by-plugin basis.

    Sorry, a lot of this is just my thinking out loud, but really, I think I just got why this makes so much sense. Users can have a choice of permissions plugins, and all plugins check those permissions in the same way. Also:

    I'd assume this would be done by the plugin manager itself (such as PermissionsBukkit), rather than Bukkit itself.
     
  3. Offline

    Drakia

    In regards to "The permissions API which bukkit has included is -just- an API/Framework. It does nothing without a helper plugin." Then why even bother? As it is most (Every?) Permissions plugin supports the core Permissions API, we as developers came to this conclusion MONTHS ago, and it is a MUCH better system.
    This system is a step backwards, it's a stripped-down terrible fix to a problem that the community already solved. The bukkit team seems to have completely ignored everything that plugin devs wanted, everything that the current set of Permissions plugins implemented, and everything that users were expecting, and went with something that is completely useless on its own, lacks basic features such as groups/variables (Which, to me, DO belong in the centralized Permissions plugin, as they are technically "permissions" that contain strings), and is pretty much a waste of time to code for.
    There is ZERO reason to update plugins to this new system, users AND devs wanted a centralized Permissions system that supported the features they already had, this is not that.

    New does not always equal better, and this is a great example of that.
     
    aPunch likes this.
  4. Offline

    Celtic Minstrel

    So that plugin developers don't have to worry about what permissions system their users are using; they'll automatically work no matter what permissions system the server administrator chooses.

    The Permissions API is not a much better system, either. In fact, this API is basically identical to what already exists, except without requiring a plugin and without having a built-in notion of groups (which, as has been said several times, is not an essential component of a permissions system).

    Imjake9's musings suddenly made me think; could a cooldown system be implemented by setting "permission.to.do.that: false" for some specified period of time? Though this is probably not the best way to implement cooldowns, since it doesn't distinguish between "You're not allowed to do that at all" and "You did that a moment ago, so you can't do it for another three hours".
     
  5. Offline

    Drakia

    It already works like that, every Permissions plugin out there has a bridge that gives any plugin using the "Permissions" API access to it. This is what I was referring to when I said the community has already solved this issue long before Bukkit even started looking into it.

    This API does require a plugin if you want it to be usable in any sense of the word, don't even attempt to convince me otherwise. As it was, most plugins that used Permissions worked perfectly fine without Permissions, and just used isOp() this is no different than just relying on isOp(). If you want access to groups, you still require coding for a specific plugin. This system is a waste of time and should be removed/rewritten.
     
  6. Consider reloading circa 80-120 permissions (remember, we can't wildcard them) for 50 active users. Do you honestly believe this won't cause lag?

    Granted GM/P3 still have lag on reloads, but wildcards help alliviate it by only loading one permission "rule" for all it's sub nodes.
     
  7. Offline

    xZise

    I didn't test it yet, but the permission registering is kind of a problem. For example I want a permission for every warp, that the user can warp to this. At the moment I simply ask Permissions 3 if the user have the permission node. But with this here I have to register this permission first. Now this could be done, but when somebody deletes the warp, The best would be, if I could remove this registered permission.

    Another problem is – as there aren't groups anymore – that I added a option, that a user could edit the warp, if the user has a permission. This permission could be chosen by the user. Now with Permission 3 I don't bother, as I simply could use the string given by the user. But with Bukkit Permissions it will return that the permission wasn't set, if nobody registered it. But when could I register it and when not.

    Also the lack of permissions values are kind of a problem. If there won't be such a system, I simply return the corresponding default value. Now this maybe make the API more complex, but those plugins which don't want to support this could return a default value. But at the moment it isn't possible to store values/constants to a specific user.

    Also there should be some kind of “select all permissions starting with ....” as a child. By adding manually each value, this is firstly annoying (especially if you have many) and prone to forgotten permissions.

    Fabian
     
  8. Offline

    Dinnerbone Bukkit Team Member

    You do not have to register permissions to use them. You can just use them, and not give a care in the world. You only have to register them if you want them to have defaults or children.

    And "the community has already solved this issue long before Bukkit even started looking into it." - We were figuring out the best permission system to use before we even started Bukkit. The current Permissions plugin is based off an early design that we had, but had fallen for all the flaws that we specifically set out to avoid.
     
  9. Oh. Really? Well shit... this makes life a considerable amount better. This should be added to the first post.
     
  10. Offline

    Dinnerbone Bukkit Team Member

    It is. "For plugin developers" -> "Do I have to register my permissions in plugin.yml?"
     
  11. Offline

    Celtic Minstrel

    Requiring an extra plugin in order to use your preferred Permissions plugin doesn't sound reasonable to me.

    Not true; read on...

    Exactly, this permissions API without a supporting plugin is pretty much the same as relying on isOp(), except now the server administrator has control of which permissions are given to ops only, rather than the plugin developer. So, it's increased flexibility over isOp().
     
  12. Offline

    Mordenkainen

    Still having some problems understanding how to handle dynamic permissions.

    If I have a node:
    MyPlugin.MyNodes.*

    And at runtime I have a bunch of dynamic items that I want to be children of Myplugin.Mynode (MyPlugin.Mynode.1, MyPluginMynode.2, etc.). How do I accomplish this with this permissions system?

    From what I am reading, I can dynamically create the new permission nodes, but I can not make them children of MyPlugin.MyNodes. Because of this, if the permission MyPlugin.MyNodes.* is assigned to a user, it will not include the dynamic nodes?

    How do I create a setup that will work if I check MyPlugin.Mynode.1 against a user that has permission MyPlugin.MyNodes.*?

    Or, perhaps I am just misunderstanding how the new system is working.....

    Also, If I understand correctly, you set a default value for each permission in the plugin.yml. This is the value returned if the player does not have the permission correct? So unless I want the addition of the permission to the player to be a "deny" permission, my defaults must all be false if I want the server admin to have control of who gets permission to that node? (I.E. Having to explicitly grant the player permission to the item controlled by the node)

    Morden.
     
  13. Offline

    Celtic Minstrel

    If the full set of children will be known at startup, you can add the permissions then. Otherwise, you can fake it by explicitly checking for the MyPlugin.MyNodes.* permission if the player doesn't have the MyPlugin.MyNode.1 permission.
     
  14. Offline

    Mordenkainen

    In that case is there a way to tell if a player has been given the following permissions:
    MyPlugin.MyNode.*: true
    MyPlugin.MyNode.1: false

    (I.E. granted all MyNode items except MyNode.1)

    The check for MyNode.1 will return false, because the user has been denied this permission, and the explicit check for MyNode.* will return true, causing the user to gain permission to a node that was explicitly denied.

    Is there some way to tell if the permission returned false because it was the default (or not present) vs. when it returns false because it has been explicitly set that way?

    EDIT -
    After thinking about it, I guess the way to accomplish what I was asking about would be to have an explicit "deny" node, like "MyPlugin.Mynode.1.Deny: true".

    Morden.
     
  15. Offline

    xZise

    Ehr:
    And if I don't register a permission, and then test this via hasPermission it won't return always false? It only assume, that the default of this permission is set to false? Sorry, didn't want to bother you but I couldn't test SuperPerms at the moment, and the sentence isn't really clear which “default” is meant.

    Fabian
     
  16. Offline

    Dinnerbone Bukkit Team Member

    If you .hasPermission("non.registered.permission"):
    - If they don't have this permission set to anything, it'll return false
    - If they do have this permission set to something, it'll return what they set

    If you .hasPermission("registered.permission"):
    - If they don't have this permission set to anything, it'll return the default value registered
    - If they do have this permission set to something, it'll return what they set
     
  17. Offline

    Celtic Minstrel

    According to the commit logs, permissions have been made mutable...?
     
  18. Offline

    Dinnerbone Bukkit Team Member

    Correct. But keep in mind using the methods won't make your plugin compatible with 1k :p
     
  19. Offline

    Xandaros

    I actually like this. And I hope all plugins will switch their permissions system immedeately.
    All this "You need GroupManager", "You need Permissions 3.x", blah, blah, was ticking me off.

    However. Give us back the *!
    It was really nice to have admins have access to *, without caring about adding the "all" permission from 40 plugins.
    Seriously -.-

    Despite the missing *, I like it. But I see another problem:
    What is with plugins actually modifying groups. Won't this cause the same ruckus?
    "You need plugin X for this to work, because it changes your group"
    ...
     
  20. Mutable as in changeable after we make them?

    This may actually be worth it, but not without wildcards.

    I'm sorry, but the "supposed drawbacks" of wildcards do not in any singular "oh god this kills everything i ever loved" way outweigh the benefits, save a few extra processing cycles.


    Do not get me wrong at all, despite my previous posts, and central mechanism for permissions is a good thing, but crappy implementation does not a plugin dev make happy to use.
     
  21. Offline

    Xandaros

    The way I did understand it, there are wildcards, but you can't have a global '*' node.
    I might be wrong, though. I guess the whole concept should be clarified a little.
    And I want my global '*' node! :mad:
     
  22. There are no wildcard searches, at all, unless you manually construct them.
     
  23. Offline

    Celtic Minstrel

    I don't think there should be automatic wildcard searches, but it would be good to have something in the API to make it easy to do manual wildcard searches. For example:
    Code:
    // pm is the plugin manager
    Map<String, Boolean> perms = pm.getPermissionsWithPrefix("general"); // note, you could either include or omit a trailing dot, and this choice would affect the result
    // potentially alter the wildcard if you want to exclude certain nodes
    Permission myWildcard = new Permission("general.*", perms);
    pm.addPermission(myWildcard);
    
    Obviously it requires that you register all your leaf permissions, but when it's mostly just the leaves in the plugin.yml I think it wouldn't be too bad.
     
  24. And it's REALLY not that difficult to construct them on the fly. I like the lack of a *.* perm and I now believe all plugins should provide ROOTNAME.* along with all subnodes, but this way, even a dangerous command (such as multiverse.core.delete, which has the power to remove world folders) can even turned off for ops by default and to a group as default.

    The mutability/deletion was what was needed! Thanks @Dinnerbone!
     
  25. True, now that the promise of mutable permissions is there, it's a little easier to update them. but plugins such as Warpz0r and multiverse which have dynamic permissions for worlds now have to explictly update there children nodes,.

    It just seems backwards to have to manually update the wildcard to attain this functionality.
     
  26. Offline

    zaph34r

    just to get a few clarifications for the plugin developer side of things:

    The .addAttachment(Plugin plugin, String name, boolean value, int ticks) adds some permission(s) which expire after x ticks, but is there any way to change the number of ticks until it expires after creation?

    And the PermissionAttachment returned is basically a collection of any number of named permissions which can also be modified after being created (adding/removing permissions from it)?

    i also want to add that i very much like the way the permissions api works, especially when the mutability is available :)
     
  27. Offline

    tyzoid

    Is there any way to check if the bukkit permissions exists? (There might be users using builds under 1000)
     
  28. Offline

    Celtic Minstrel

    @tyzoid
    Code:
    try {
        Permission test = new Permission("test");
        // ignore the test variable and proceed to do stuff requiring permissions
    } catch(ClassNotFoundException e) {
        // do stuff not needing permissions
    }
    
    I think that should work, though it's inelegant and using some method in Class to actually check for the existence of the Permission class would probably be better.
     
  29. Offline

    tyzoid


    I tested this, and it doesn't yield an exception.
     
  30. Offline

    nisovin

    It does. Looks something like this:
    Code:
    16:46:10 [SEVERE] Error occurred while enabling Test v1.0 (Is it up to date?): T
    he permission test.test is already defined!
    java.lang.IllegalArgumentException: The permission test.test is already defined!
    
            at org.bukkit.plugin.SimplePluginManager.addPermission(SimplePluginManag
    er.java:417)
            at com.nisovin.test.Test.onEnable(Test.java:22)
            at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:126)
            at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader
    .java:878)
            at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManage
    r.java:272)
            at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:162)
            at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:146
    )
            at net.minecraft.server.MinecraftServer.e(MinecraftServer.java:284)
            at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:271)
            at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:148)
            at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:335)
            at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
    
     
Thread Status:
Not open for further replies.

Share This Page