Permissions vs. configuration and the use of '*'

Discussion in 'Bukkit Discussion' started by zolcos, Jul 8, 2012.

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

    zolcos

    The way I see it, and this is a totally debatable point, is that permissions are for granting access to features, and configuration is for controlling the behavior of your plugin. When plugin developers follow this guideline (perms=access, config=behavior) all is well in the world and it provides a few conveniences, such as the ability to give yourself many permissions on your own server while you are still in the "research" phase of the plugins you are configuring, while resting assured that doing this just gives you access to things and won't actually make the plugins start doing anything weird.

    However, some developers have noticed that permissions are a convenient way to set arbitrary flags per-player and have started shoehorning the configuration of plugin behaviors into the permissions system. However, in every case I've seen, the same functionality can be implemented in a slightly different way, without much extra effort, while not breaking the concept of config&perms. Unfortunately, there seems to be something of a religious war over the object of this discussion. I speak of course of the '*' permission. (cue flames)

    It's a perfectly serviceable concept in theory, you're just giving yourself all the keys so to speak. But only when developers break the implied rules, do problems happen.

    Don't get me wrong, I'm not trying to bash developers -- I'm a plugin developer myself, mainly of the moderately complex CommandShops and I haven't broken my own advice. This thread is more of a debate/PSA than any kind of demand, since when a plugin is made this way, the problem can usually be worked around.

    Now, for this to make any sense, I must give examples. It will be extremely useful to illustrate the subject at hand and is not intended to be a callout.

    VanishNoPacket has permission nodes that make uncontrollable explosions and lightning appear around you when you vanish or unvanish. If you give yourself these accidentally, it of course hampers use of the plugin's core feature.
    THE EASY FIX: Make those same permission nodes allow you to use a parameter on the vanish command that makes the SFX happen.

    Spout has a particularly nasty feature where some permissions actually take permission away from you. If you use *, you actually have to use negative permissions on these anti-permissions in order to give yourself access to things. At least it's a good example of a double negative. Negative permissions aren't a very stable feature in some perms plugins though.
    The node I speak of here is the one that, when set, forces the player to use spoutcraft to connect to the server. Keep in mind the literal meaning of this permission is "This player has the permission to... not have permission to connect with non-spout clients".
    THE EASY FIX: Make the spoutcraft requirement a global config option and give individual players a bypass permission. Thus your granularity of control is the same.

    Aside from the avoidance of problems like that, abiding by these concepts will also eliminate having to add more permissions every time you update all your plugins and a few inevitably add more features. Heck, using '*' even provides an auxiliary way to notice new features!

    What I'm proposing makes the server admin game a bit more pleasant while making things 0% harder for developers. However, when the issue is brought up in the thread for a specific plugin, as soon as someone reveals they are using '*' the dev stops listening to them and just uses the issue to soapbox about why '*' is so evil and that everyone should just do their perms 'properly'. By their logic, the best plugin would be one where your players just type java code into the chat box and it gets auto compiled and loaded as a new command. You'd be able to claim the greatest number of features of any plugin! It would take you a lot less man-hours to develop than a lot of popular plugins, too. :)

    I would enjoy being corrected on this point since it would be a huge revelation to me, but it seems that there is literally no existing case where a plugin significantly benefits from violating the perms/config relationship.
     
  2. Offline

    TnT

    Do you run your server under the root account? If so, do you believe that is a good idea?
     
  3. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    "*" isn't evil. But, any server admin using * needs to also acknowledge that it's their responsibility to read the entire documentation of a plugin's permissions to ensure they aren't giving themselves any nodes they don't want, and to appropriately negate the nodes they wish to avoid. Giving yourself * and then not reading documentation is like walking into an ice cream parlor and asking for a sundae with everything on it, and then complaining about it having nuts and whipped cream.

    In the case of VanishNoPacket, the lightning and other effects permission nodes function as "This user has permission to be struck by lightning/explode/etc each time they vanish." It's a finer grained control than config based, and fits perfectly within the true/false access/no-access system of permissions.
     
  4. Offline

    zolcos

    No, but if I did, it wouldn't immediately break stuff.

    I'd say it's more like summoning an ice cream parlor that has 100 flavors instead of 10. I can still order whatever. (and complain about getting sprayed with whipped cream as soon as I walk in)

    Except that's not what happens. Instead of being given permission to be struck by lightning, they are forcibly struck by lightning.
    You can get the same granularity using those perms to control access to a sfx parameter.

    Ultimately, there is still no benefit to breaking '*', other than generating opportunities to be condescending to people. It doesn't make a plugin significantly easier to code, so what's the defense of it?
     
  5. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    The lightning node is the permission for "On /vanish, you get struck by lightning." Without it, you /vanish without lightning.

    This discussion is starting to sound more like you're just upset that setting "*" without reading documentation results in unexpected-due-to-not-reading consequences.


    Look at mcmmo for an excellent example of using permissions for features not just commands.
     
  6. Offline

    TnT

    You sure? Because being silly with the root user is going to be just as disastrous as being silly with the * node.
     
  7. Offline

    zolcos

    McMMO is probably the best example of an edge case you will find, and all the perms are still in the form "Allows access to _____" instead of "Causes ______".
    Either way, I'm not saying there will never be a valid case to break a convention, I'm saying that all cases I've seen so far have been unneccessary and that, in general, it is easily avoided and there are benefits to doing so.
    Let's not resort to flames please. I know you feel the need to defend your plugin but I'm not targeting you; it's a widespread issue.
     
  8. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    zolcos apologies, I didn't intend for it to be flame, just that it seems to me that this is an argument that's only an issue when users fail to read documentation.

    Let's try another example from my plugin: Joining silently.

    If I wish to establish, in the cleanest manner possible, which users can join the server silently and which join instantly how would you propose doing this in a way that isn't permission node based.

    Let's take a slightly further step. If I'd like let admins define, on a global or group-based scale, the effects that occur on using the /vanish command how would you propose doing this in a way that isn't permission node based.

    The only alternative solutions I see are these two:

    Create a list of users who cause X
    This method bothers me, because it means the server admin goes from managing a single permissions list to managing multiple on a per-plugin basis.

    Handle any optional feature user-input-based
    Not all cases (see silent joining above) can be handled by user-input. And for other cases it can quickly turn into command bloat. And, to use the lightning example, what if I don't want the user to be able to prevent the effect? It quickly becomes a complicated mess.
     
  9. Offline

    Lolmewn

    I do. Problem?

    Oh, @ OP, tl;dr ;)
     
  10. Offline

    zolcos

    Now this is a convincing case. The decision on whether someone's join should be silent has to be made before they login, so of course it's pretty hard to get the users' input on it. But not impossible, in fact I can think of a pretty good way that's clean and simple from the admin and users point of view, but is undoubtedly more work to implement so I can at least see why you'd do it the easy way and won't criticize it for being 'arbitrary' even if it is still avoidable.

    If there's anything you don't want a person to have control over, you wouldn't be giving them '*' in the first place

    No matter how many times I read the documentation, your plugin still breaks a feature of my permissions system >_>

    The below is just a side note -- I'm not necessarily recommending that you do this but I figured you might ask what my solution was to silent joining without breaking '*':
    Listen on another port in a way that looks like a server, and when players with permission to silentjoin connect to it, their client gets connected to the 'real' server but silently. So in their serverlist they'd have "baxtercraft" and "baxtercraft_silent". If they're smart enough to have become an admin on someone's server they should be able to handle it.
    Not easy or simple to implement of course but it actually sounds like a fun challenge.

    Note though, that regardless of design principles, your current structure doesn't allow for someone to make their own choice to join silently at all, no matter how they set up their permissions. So that last change wouldn't be a restructure just for '*', it would also be adding a big new feature.
     
  11. Offline

    dxwarlock

    Perhaps I misread it? but you saying VanishNopacket with using the "*' has no way to join/vanish/teleport to people silently?

    Been using '*' for 2 years on my Admin Node (just me) and with a tweak here and there of '- -whatever' has been great for me. Most my groups have looong complicated permission nodes. mine (admin) has like 5...4 "- -something" and a '*'.

    Id be one of the few majorly miffed if '*' was reordered or changed, now its 'easy mode perms' as some put it.
    Not so much an 'easy mode' perm to me, as it is a "I don't want to add 5000 permissions to my group, that one wildcard can cover."
     
  12. Offline

    zolcos

    No, it's just that having the permission node makes it always happen, you can't switch between silent or not without changing your perms. But you can't change your perms without going ingame (unless you have console or shell access) which is tricky for silent join.

    This thread isn't to complain about that though, just the '*' node
     
  13. Offline

    Sagacious_Zed Bukkit Docs

    There is an additional compromise, assuming the permission manager behaves itself, is that your plugins.* node does not contain all permission nodes. Since plugins are allowed to define what is in the plugin.* node. If it was restricted to permissions, in the sense of you are allowed to do something, then I think it would behave mostly as people expect, that those are all permissions and not flags. Again as with all the permissions, it is still up to the discretion of the plugin author on how to alias these.

    zolcos
    In the event a plugin kept a list of who should log in silently itself, you can't change that unless you are in game. Unless you have console or shell access or said plugin has an additional interface for configuring silent join.
     
  14. Offline

    zolcos

    I'm not sure what you're referring to here or what you mean by it since I never suggested that
     
  15. Offline

    Sagacious_Zed Bukkit Docs

    Sorry, I'm just pointing out no matter the method used to flag players, it is always an issue.
     
  16. Offline

    zolcos

    Except the method I posted...
     
Thread Status:
Not open for further replies.

Share This Page