Permissions FAQ

That actually makes some sense to me, thank you that help alot XD

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?

This is something we would define ourselves in the permissions.yml file? I'm still a bit uncertain on how that should be formatted...

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?

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.

I'm liking "Privileges"

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.

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.

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:

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.

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.

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.

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).

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.

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.

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.

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.

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...

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.

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.

Seeing these new permissions i feel kinda dumb lol.

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.

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

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.

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)...

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.