Permissions FAQ

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

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

    4am

    This is something we would define ourselves in the permissions.yml file? I'm still a bit uncertain on how that should be formatted...
     
  2. So we move from a system of wild card permission nodes to one where we define a custom node that adds all "children"?

    Also, are children of children resolved?
     
  3. Offline

    4am

    I believe you're thinking about this the wrong way, let me see if I can explain this.

    Just like before, plugins define permission "nodes", like "thisplugin.dosomething", "thisplugin.admin.something" and "thisplugin.admin.somethingelse". When a user performs the corrosponding command, the plugin calls .hasPermission("<node>") to check if the action is permitted (of course, replace <node> with the appropriate node above).

    Plugins (or admins, in the permissions.yml file) can also define nodes which group other nodes together, such as "thisplugin.admin.*". The difference here is that the * has no special meaning; it's just another name - Using "thisplugin.admin.all" or "thisplugin.admin.gasolinepotatotennis" could work exactly the same way.

    When a user is assigned this "catch-all" parent node, Bukkit instead assignes the child nodes as defined; some may be true, some may be false, some may be op-only, others non-op.

    If done correctly (this is the part that may take authors and admins some getting used to, because it is different from what we did before), you can have groups like "thisplugin.moderator" and "thisplugin.admin" or even "thisplugin.all" as a SINGLE NODE that needs to be assigned to a user. This makes configuration easier, and checking permissions doesn't first need to check for the individual node itself, then match wildcards, THEN check for negative nodes, etc. which is way more work and leaves more ways for things to go wrong. Instead giving users access to all nodes and then attempting to remove what you don't want them to have, this has a very defined structure for what you are defining at any given time, which is faster and more secure than wildcard methods.

    The fact that users can define their own node groups like this also allows for flexibility that even the plugin authors didn't think of, or are not appropriate to implement for every user of a plugin (sever-specific definitions of "thisplugin.moderator" for example.

    The wildcard is obsolete with this system.

    This is *almost* like defining groups, and you could possibly make a system of simple groups this way in your permissions.yml, but it would be messy as that is not the intended use of the feature.
     
  4. Offline

    VeryInsane

    I'm liking "Privileges" :D
     
  5. I think it might be lack of a fuller FAQ that's causing all the hoo hah about this. Dinnerbone's OP doesn't really delve into the technical side that the plugin Dev's need to understand this. Rather we need to read the entire javadoc for the package to understand it.

    For instance, I didn't understand till i read permissable.java that you can have timed permissions.

    I still stand by my judgement that * is a useful special node. But the rest of the features (permissionAttachments, callbacks, timed PA's) make more sense now.

    TL;DR: Go through the javadoc's for this first if you're a plugin dev, makes more sense how they did it if you can see what it can do, rather then what it can't.
     
  6. Offline

    Sleaker

    I thought this was one of the main features of multigroup. The only difference then would be how they are resolved. This system is just more suggestive on using groupings than the previous systems, but you could and probably should have, been doing this already with pex/p3.
     
  7. Offline

    jdawg307

    i'm testing out this system and i have essentials.warp set to true and yet he can't warp..... can someone help me out?


    Code:
    users:
          Xx_Lakers_xX:
           permissions:
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: false
        admin:
            permissions:
                permissions.*: true
                essentials.warp: true
            inheritance:
            - user
        user:
            permissions:
                permissions.build: true
            inheritance:
     
  8. Offline

    Mixcoatl

    That's the same as saying groups will not be handled.

    If Bukkit is supporting groups as a tertiary function of permissions it needs to support at least a minimal set of functionality. Telling us we have groups and then that we can't do any group stuff with them without directly referencing a plug-in is just not acceptable.

    The problem derives from the fact that server operators may choose to use different plug-ins to implement the permission backend. Because of this, I cannot write a plug-in that depends upon this functionality without intentionally excluding prospective users. Again, unacceptable.
    I have actually abstained from existing permission plug-ins for the very reason I have described above. To write a plug-in to work with one permission plug-in often limits your prospective user base to only those server operators that prefer that implementation.
    Permission groups and roles is the correct way to implement a "simple" model. This model, as it exists now, cannot support a more complicated permission system. It's only useful for the most simple case, which means it will not be useful in the general case -- often a mix of simple and complex scenarios.
    And, again, I will not create a dependency on a plug-in a server operator can choose not to install, or to select from one of half-dozen, as is the case with permissions plug-ins right now. Having to create proxies and bridges to support various configurations of permission plug-ins with different feature sets is not acceptable.
    I see only the simplest case, not the extensible case. I don't see anything here that allows me to extend permissions to meet my needs without tightly coupling my plug-in to some permission implementation that server operators may casually prefer not to install.

    I've got no problem with permissions, themselves. I was even fine with boolean-only permissions. I have a problem with the complete lack of dynamic support and the inability to treat permissions as groups whilst being told by Bukkit developers that permissions are groups.
    This example will not work unless your classes are hard-coded. If they're built in meta-data, as mine generally are, and created, deleted, and manipulated at run-time, as mine generally are, I simply cannot use this permission system without tremendous heartburn.
    My mind is hardly closed. You're completely failing to understand that this is a significant issue for many of us, and then trying to tell us that it's our fault for wanting something we were told we were getting.
     
    spelmyst likes this.
  9. Offline

    Celtic Minstrel

    Unless you forgot to install SuperpermsBridge, I can't say what the problem might be.

    Correct, Bukkit has permissions only, not groups.

    Um, we don't have groups. That's why you still need a plugin for groups.

    That's why you have Bukkit permissions, so that you can use permissions without supporting only a specific permissions plugin.

    Groups and roles is something that could probably be implemented on top of the Bukkit permissions without too much trouble. SpaceManiac has already done groups, anyway, and I'm not sure how roles would differ from groups.

    But as I said, that's what Bukkit permissions solves. You don't need to care about what permissions plugin they're using, or if they're even using one at all. You just ask Bukkit if the player has a permission, and Bukkit tells you.

    Extend in what way? I can't think of many ways to extend it apart from maybe adding integer permissions.

    They're not groups, but they do have the capacity to function as a crude implementation of groups without an additional groups plugin.

    If you mean the permissions you check for fluctuate wildly at runtime, that's okay; just don't define them, and explicitly check for wildcards before checking for their apparent child nodes. It's a little more work in the checking, but apart from that I don't see that anything will change.
     
  10. Offline

    Mixcoatl

    Then DinnerBone should not have insinuated earlier in the thread that groups were omitted because they could be implemented by defining permissions.
    That's a major let-down. Especially considering that I offered to contribute this functionality over six months ago and was shot down because something better was allegedly coming.
    Unless you need to be able to tell who has a known permission or modify permissions at run-time to support pseudo-groups.
    It would work if Bukkit were to support dynamic permissions.
    If there is any relationship between groups and permissions, as there is for most everyone out there who is using some permission plug-in, the problem is not resolved as I see it.
    If certain baseline functionality were added, yes. If one cannot test or modify group membership using the existing interfaces, they cannot function as rudimentary groups.
    I mean the permissions which need to be defined and undefined vary at run-time as server operators invoke commands to dynamically create and remove objects from the database.
     
  11. Offline

    Dinnerbone Bukkit Team Member

    I'm sorry if any of my posts have given you that impression, but it was far from what I meant. Groups were omitted because you don't "need" groups, and those who do need them are to fulfil different roles. I can run a server with just users and ops and permissions will work fine splitting normally by defaults, no groups involved.
     
  12. Offline

    4am

    Yes, I also fail to see the need for a plugin (which is not a permissions manager) to have a specific need to reference a group?

    Use cases for nodes containing variable data types (prefix and suffix for example) I can see a case for; but I understand why it was not implemented (added complexity, plus it can be implemented other ways).
     
  13. Offline

    Celtic Minstrel

    Um, the former is possible. The immutability of permissions, though, and the inability to delete one that is registered, is slightly annoying.

    I think for this case you could likely get away with just not defining any of the permissions. A permission doesn't need to be defined in order for a player to have it.
     
  14. Offline

    Mixcoatl

    Alright. I think I'm clear about the intention. Permissions are really not what I was waiting for, then.
    Groups aren't needed only so long as permissions are robust enough to fill their role. But based upon the description I've read here, permissions are nowhere near strong enough to perform as groups, and it sounds like this was the intention while permissions were under development.

    Based upon that assertion, I would like to formally request some combination of dynamic permission support and group functionality support. Note: what I'm referring to as a "group" is really a role, a collection of permissions related to some function, but not necessarily related to each other hierarchically.
     
  15. I think people are freaking out a little too much about the lack of groups. As Dinnerbone and others have stated, they are simply not needed. Ever. At All.

    For example:
    MV2 used to allow you to set a groupwhitelist, for world entry. This was a bandaid and a bad idea.

    Bam, Whitelist gone.

    Now ALL worlds require a permission: "multivers.access.WORLDNAME" Each world, when it's created, creates this permission.

    Now, groups. Let's say we only want admins to have access to a world named "admins". All you do is simply give users in the group permsision to "multiverse.access.admins"

    This way, our plugins don't need to even know about groups! I have completely removed all notion of groups from MV2 to not only support Bukkit's permissions, but also for other plugins! Groups from a developer's perspective are not needed at all!

    I agree entirely with this though, Anything that can be acomplished with a server restart, should be able to be done without a server restart.

    I had a post on about the 1st or second page, as well as many other devs asking questions about deletion (I can almost live with the immutability) and none of them have gotten a solid response for why this was decided on.

    Example of deletion:
    If I create a world(fern), then delete it, now I have an orphaned permission(multiverse.access.fern) that will be never present after a restart. This is not a good thing. Ever. In addition, for portals, this is even more important, as servers will go days without a restart, and portals/warps will get created and deleted hourly!

    Guss I'm just hoping to get a response why the decision was made for lack of deletion.
     
  16. Offline

    Mixcoatl

    The most basic example is to write a command that displays which users are, let's say, event administrators. What I was hoping for is to get the set of players who have permission "group.event-admin" and display that set. The uses are myriad this is just one tiny, tiny example. Chat plug-ins, clan plug-ins, PvP plug-ins, town/nation plug-ins, and so on could all depend upon this, especially when commands are controlled by group membership, not permission level.

    If I have to reference a plug-in directly, rather than the Bukkit API interfaces, something is broken.
    And that's the case that doesn't bother me. ;)
     
  17. Offline

    Celtic Minstrel

    So, you're saying Bukkit is lacking a way to see the set of players that have some specific permission? If you only want online players, this is actually possible already by looping through all players and checking if they have the permission, though I can see that that may be less than ideal if you have a lot of players...
     
  18. Offline

    Mixcoatl

    I'm sorry, but whether permissions solves this problem or not, that's a naive position to take. Groups and roles are a foundational element of virtually every permission system in the real world -- at the OS level, at the application level, etc.

    My confusion arises from the insinuation on the first page of this thread that permissions could function as groups. As it turns out, this is really not what DinnerBone meant. What he should have said is, "You may need groups, but this does not deliver them and cannot be made to function the way most developers, players, and server operators expect groups to function."

    Then the rest of us would just go back to pining and waiting, or using some one-off plug-in solution to resolve our problem.

    *cough* What about offline players?

    Before I get any more hate mail ;) ;) ;), just let me clarify that after Dinnerbone's message above, it's obvious to me that this feature was never intended to give developers or server operators any sort of functional roles or groups. For controlling access to a limited set of known commands, what we have here in CB1000 is probably more than adequate.

    But I still want to see official group/role support. ;)

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 17, 2016
  19. You're right. They are. but this is an API. This is not ment to be an implementation. I think this is the big item that gets overlooked. The API should be the lowest level that can get things done without superflous requirements.

    If groups were made a part of this, every Permissions plugin would have to support groups. I do not think groups are a requirement, but from a Permissison Plugin perspective, they are a great idea. The point is without groups it actually makes our lives as developers easier. Why do I care if user A is in group B if I can just say does user A have permission to blow up life, the universe and everything.

    I got to cut around 200 lines of code when I realized groups were not needed, in addition, I now don't have to worry about the bugs associated with said lines of code. In addition, I no longer have to store those groups, or make my users set them up. Again, I mean no hostility, this is merely my opinion on the matter. :)
     
  20. Seeing these new permissions i feel kinda dumb lol.
     
  21. Offline

    Mixcoatl

    I don't care if the Bukkit team provides the implementation or not so long as I only have to refer to the interface and never, ever the implementation. The day I have to call pm.getPlugin("Permissions") to do what I need to do with Bukkit permissions, it's broken.
    Permissions function perfectly as groups as long as the API is strong enough to do with permissions what people need to do with groups. It's slightly more complicated, yes. But once you have the permissions bit in place, it's only a few additional methods.
    Again, I have no problem with Bukkit not providing the implementation. I just want an interface strong enough to support what I intend to do. The implementation can be pushed off onto plug-in developers so long as a plug-in using Bukkit permissions never needs to know or care.
    I really don't mean to be hostile, either. It just rubs me a little raw because I offered to contribute code to provide nested role-based permission functionality six months ago, and my offer fell on deaf ears.
     
  22. Offline

    Celtic Minstrel

    I thought you might say that. :p It'd be a nice thing to have, certainly.
     
  23. Offline

    Mixcoatl

    Yep. But, to be entirely fair, I foolishly hadn't thought about iterating the player list. It would be slower, but not horrible considering the generally low population of most servers. Bigger servers could always throw more resources at it to solve the problem.
     
  24. Offline

    4am

    All those cases are already accounted for - you can tell who is a group based on the nodes they have - if you're posting some event log to the admin group - does the user have yourplugin.admin.event? Make sure your permission managing plugin has yourplugin.admin.event assigned to the group.

    Now, it would be nice to do a reverse-lookup and see which users have been assigned certain nodes (I'm not sure if this can be done or not)...
     
  25. Offline

    Mixcoatl

    They're not really accounted for, no, but I understand where the discrepancy is now.
    I was looking for something like this:
    Code:
    void foo(CommandSender sender, Permission group) {
      // Online and offline players in the group.
      for (String playerName: group.getMembers() {
        sender.sendMessage("Woo! " + playerName + "!");
      }
    }
    We can get halfway there with something like this:
    Code:
    void foo(CommandSender sender, String groupName) {
      // Only online players.
      for (Player p: getServer().getOnlinePlayers()) {
        if (!p.hasPermission(groupName))
          continue;
        sender.sendMessage("Woo! " + p.getName() + "!");
      }
    }
    But we obviously lose the ability to tell which players are in the group but offline.
     
  26. Offline

    EdGruberman

    I would think groups provide the advantage of assigning common permission sets to a single security principal, then adding other security principals (users) to that group automatically grants them all the already assigned permissions.

    If I have to assign new users their own permissions in each plugin I'm running each time a new user needs them, that's an administrative nightmare for me.

    And the most common "simple" scenario to me is Admins, Mods, Players, at least three groups. I'm also not sure why groups were seemingly discarded as irrelevant for this feature. It really seems complimentary.

    Also, I can think of at least a few "common" situations where a player would want to be able to mess with groups and their members... Things like regions come immediately to mind where a region owner would want to work with a list of users and groups to assign them access. The idea that the player would have to somehow be given an interface to assign each user by name a permission by name is unfathomable on the amount of sheer typing that player would have to do in-game versus leveraging a group solution where they might have to instead just type: "/region add [Group1]"

    If the suggestion is the region plugin implement it's own group solution, then that group is isolated to that plugin and other plugins can not leverage it and you now have plugin related groups each stored in their own repository. I'm not sure how that's better.

    I'm also not sure what is wrong with wildcarded permissions. The wildcard is simply a textual representation of inheritance flag. Inheritance is very common in permissions systems and provides flexibility. I seemed to find an implementation for such: https://github.com/EdGruberman/Acce...src/edgruberman/accesscontrol/Policy.java#L64
    https://github.com/EdGruberman/Acce.../edgruberman/accesscontrol/Privilege.java#L57
     
    Mixcoatl likes this.
  27. Offline

    Celtic Minstrel

    I don't really see anything inherently wrong with wildcards, but there are situations in which they can cause problems, and the universal wildcard '*' is the most prone to these. It might be nice to have a method in the Bukkit API and/or the plugin.yml to use as a sort of shorthand for creating wildcard permissions, but having it automatically recognize wildcard permissions isn't necessarily what you want in all cases.
     
  28. Offline

    4am

    Everyone needs to go back, read the FAQ again, and wake up from this nightmare. This simply isn't true, and I'm not going to post about it anymore.
     
  29. Offline

    speeddemon92

    Hmm this update is even more of a nightmare for me than i had hoped as I'm both a dev AND a server admin. none of this will work with my load without stackoverflows nor is it simple enough...I think i'm going back to coding Cerberus and Synapse and ridding myself of this nightmare until it is fixed
     
  30. Offline

    ToastedJelly

    Well. We could also omit groups from windows and assign permissions to every single user, but that's not practical. How would I have a GUI where I can assign additional permissions to my admins? List all users that have a pseudo-group-permission and use that "group" to add additional? How do I list all Groups?

    If the bukkit permissions will not provide all features that are common to all permission systems we have today, like groups and we have to add references to those plugins again, why bother with bukkit permissions anyway? If I need permissionProxy.getGroup(player) anyway, you can be sure this will have a has() method too.

    Also, why does bukkit cache the permissions when the plugin itself may have a better idea how to cache it efficient? like when it implements groups and permissions are attached to those groups, the plugin only needs to cache user/group and group/permissions and not a copy of the permissions for every user, because it has no clue that the permissions are the same for every user in the group.

    And did I get this right that I can't find out what the permissions of the user are in another world, unless I teleport him there first?
     
    tehbeard likes this.
Thread Status:
Not open for further replies.

Share This Page