Permissions not working at all?

[liquidox]

I can't find any info or ticket about this, but for us, permissions are not working at all. Perhaps no one uses this?

I run Vault + PEX.

Even Admins can't use any command or place any chip, even with redstonechips., redstonechips.admin and redstonechips.command. added.

Any chance you could support Vault? That would fix any incompatibility issues.

Thanks!

[eisental]

Thanks for the info. I never even heard of these plugins... If any one have more details about this problem do let me know.

[liquidox]

Best solution, support: http://dev.bukkit.org/server-mods/vault/

It's a widely popular and useful, stable Permissions API. Solves all your troubles :P

[eisental]

Well, I'll look into it but isn't PEX supposed to support SuperPerms? I assumed there won't be any compatibility problems when using the bukkit permissions API.

[liquidox]

It does, but really, using Vault, just ideal. I have plenty plugins that use SuperPerms and PEX, so I think there's something wrong with your implementation, but I'm just saying, while at it, may as well switch to supporting Vault, and never having to fiddle with it, let Vault do the work :P

[Mordenkainen]

I just ran a quick test and permissions seemed to be working fine. RC uses the built in permissions system directly. I do not think the right answer is to support yet a different API for permissions when Bukkit has all the permissions RC needs built in.

I kind of suspect that whatever permissions plugin you are using is not using the built in Bukkit permissions system.

If I get a chance I'll try Vault + PEX and see what happens.

Can you post whatever file your permissions are stored in?

[liquidox]

Well, if SuperPerms worked so great, Vault wouldn't exist, and wouldn't be so popular.

Secondly, we run about 140 plugins, a great deal of them use SuperPerms directly without Vault. The only thing that sometimes happens is that nodes are default true and need to be explicitly denied. I have never seen a plugin where permissions don't work even when explicitly added...

Our PEX runs on SQL.

[Mordenkainen]

Look, vault doesn't replace SuperPems, It's not even a permissions system. It's a shim to isolate the details of permissions from a plugin, so that a plugin only needs to talk to Vault to add, remove, or otherwise modify a permission, and Vault does the work of talking to whatever actual permissions plugin is being used.

That is great, and I see why people use it. Problem is, RC uses ONE permissions call "player.hasPermission()". It doesn't add, remove, or otherwise interact with the permissions system so it has no need of the functionality vault provides. Vault is super overkill for it.

I'll try to recreate the failure, and we'll see what Tal wants to do about it.

What do you get if you use the PEX command to dump a users permission list? Does PEX say you have permission for RC? Can you provide the exact command you used to add, for example, the redstonechips.admin permission?

Also, can you post your PEX config.yml? there are some settings in it that may effect how SuperPerm based permissions are handled.

[Mordenkainen]

Ok, recreated the issue and think I have found the source. It can be recreated with only PEX, Vault is not needed.

Permissions like "redstonechips.circuit.create.transmitter" work. Permissions like "redstonechips.admin" and "redstonechips.circuit.create.*" do not. "Redstonechips.admin" is a parent node permission, which means it includes many other child nodes. It appears that PEX is setting SuperPerms for distinct child permissions, but is not for parent node permissions. You can set the parent node permission in PEX, but when you ask SuperPerms if the permission is set, it will tell you it isn't.

This would appear to be an issue in PEX. As a work around, you can explicitly set ALL the RC permissions individually, but understandably, that is a nightmare. If you want to do this, you can find all the permissions in the plugin.yml inside the redstonechips.jar.

I would follow up with the PEX developer to see if this is intentional or not. There is a PEX config setting to allow parent nodes, but it doesn't appear to work (or at least it doesn't solve this problem).

[liquidox]

Ok thanks, have filed a report at PEX.

Still wonder why I haven't run into this issue with any other plugin. We run over 140, and have used PEX since the early days :/

[Mordenkainen]

Cool,

Let us know what they say. If it is an issue with the way we are handling the permissions I'll see what can be done.

[Mordenkainen]

After following up with the PEX developers the issue has been identified.

PEX ignored the permission groups defined by the plugin, and instead assumes that "*" should give you all permissions. In the case of RC, this also gives you all the ".deny" permissions causing all activities to be denied.

While I believe this to be an error in PEX, the developer identified a different way that the groups could be done that may prevent this issue from happening. this will require more testing to ensure this method works, but may allow all the ".deny' permissions to be unneeded and they can be removed from the code.

i will update this issue with additional details as i work them out.

[eisental]

I'm all for removing the .deny nodes. Are you handling it or can you explain the possible solution?

[Mordenkainen]

I would like to test a few things first, but I was told that the deny permissions could be replaced by something like:

redstonechips.circuit.* : true
redstonechips.circuit.destroy.* : false

This combination of permissions should make it so the user can create any chip, but not destroy them (or by extension reset them). I haven't tried it to see if it actually works, but if it does, the .deny permissions are not needed at all.

We still have to keep in mind that some permission plugins, like PEX, seem to ignore the plugin.xml. So in PEX, giving someone redstonechips.* is the same as giving them redstonechips.admin, where the plugin.xml says that .admin gets higher permissions than .*. I don't think we can do anything about this on our end though.

I just have not had time to test this to see if it works.