+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Permission Inheritance (/thread-1955.html)
Permission Inheritance - Shadowraix - 05-18-2015
Let's say you are using info.lua to setup your permission system.
When you have the permission for a subcommand, you can only use that subcommand. Fairly reasonable.
Although, I think that if you have permission to the command then you should be granted access to all sub commands.
Why?
It's conveniant so I can do something like plugin.* as a permission to grant all permissions. This is useful for ranks to be assigned full use of plugins without adding each one one by one. This was very tedious for me when I used bukkit when plugins didn't include it. It's also a much easier solution than doing permission checking in each handler function.
RE: Permission Inheritance - xoft - 05-18-2015
That's not a good idea, because of the multi-word commands based on a single word. Let's consider the Gallery plugin: it has a "/gallery claim" command and "/gallery reset" command. The first one should be available to all players, the second one should be available only to admins. So there's just no way to have "one command sets permissions for all commands"
When you write a plugin, you should structure your permissions properly (Gallery is a poor example, unfortunately). Make a guess at what the groups for individual commands are, and make use of permission subgroups:
"plugin.user.something1"
"plugin.user.something2"
"plugin.admin.dangerous1"
"plugin.admin.dangerous2"
This way admins can add "plugin.user.*" permission to their user rank and be done with it.
Of course, MCS supports "antipermissions", too. You can add the permission "gallery.*" and then specify restrictions as "gallery.admin.*".
I'd say these are powerful enough for most cases.
RE: Permission Inheritance - Shadowraix - 05-18-2015
(05-18-2015, 06:25 AM)xoft Wrote: That's not a good idea, because of the multi-word commands based on a single word. Let's consider the Gallery plugin: it has a "/gallery claim" command and "/gallery reset" command. The first one should be available to all players, the second one should be available only to admins. So there's just no way to have "one command sets permissions for all commands"
When you write a plugin, you should structure your permissions properly (Gallery is a poor example, unfortunately). Make a guess at what the groups for individual commands are, and make use of permission subgroups:
"plugin.user.something1"
"plugin.user.something2"
"plugin.admin.dangerous1"
"plugin.admin.dangerous2"
This way admins can add "plugin.user.*" permission to their user rank and be done with it.
Of course, MCS supports "antipermissions", too. You can add the permission "gallery.*" and then specify restrictions as "gallery.admin.*".
I'd say these are powerful enough for most cases.
I think you didn't understand my point. What I was saying, players are completely irrelevant. What I was saying is that doing gallery.* granted access to all sub commands. The multi-word commands. Some way to cut down from typing out EVERY command. Does MCS support .* to give all permissions of the sub permission? Like plugin.admin.* plugin.* plugin.user.*
And what about rank inheritance? Is that implemented?
RE: Permission Inheritance - LO1ZB - 05-18-2015
(05-18-2015, 07:10 AM)Shadowraix Wrote: Does MCS support .* to give all permissions of the sub permission? Like plugin.admin.* plugin.* plugin.user.*
And what about rank inheritance? Is that implemented?
In short:
Yes, no.
RE: Permission Inheritance - Serial - 05-19-2015
well the default permission in core is * which has a permission group name 'Everything' so yes I would say it supports the wildcard for 'all sub.permissions of x permission'
it's just good practice to not use it unless needed because sometimes using the wildcard will also give you negative permissions... for example
permission.*
could include
permission.deny.*
which could be a permission used to deny access to a command or feature.
RE: Permission Inheritance - xoft - 05-19-2015
We should never have a "permission.deny.something" kind of a permission. That would be a very poorly written plugin. Instead, the server does, in fact, support restrictions (permissions that are explicitly denied for the player), so that you can give players the "gallery.*" permission and then give them "gallery.admin.*" restriction, and it works as you'd expect - they can do user stuff, but not admin stuff.
RE: Permission Inheritance - Serial - 05-20-2015
(05-19-2015, 04:36 PM)xoft Wrote: We should never have a "permission.deny.something" kind of a permission. That would be a very poorly written plugin. Instead, the server does, in fact, support restrictions (permissions that are explicitly denied for the player), so that you can give players the "gallery.*" permission and then give them "gallery.admin.*" restriction, and it works as you'd expect - they can do user stuff, but not admin stuff.
I agree that negative permission should not exist but in some instance for bukkit plugins , they have but whether or not it was even needed I can't answer it was a long time ago that I had dealt with it.