Centrally managed custom permissions in YAML

    This is a bit (more like a kilobyte) of an add on to Miwarre's suggestion to add some functions to the API to retrieve the group names or group the player is in. This is fine but I'd like to also see a way to add custom values to the permissions. I know we can add custom attributes already can be added to the Player table but that's very 2-dimmensional. I'd like to see the ability to add more complex data in a format that's admin friendly to read.


    The following you can pass a string in with the name of the group you are interested in and optionally a node. Now I'm not sure how to represent the node or what kind of returned data structure these should yield. I like working with JSON but I'm more of a Python guy so I'm not sure how easy it is to manipulate a JSON object in Java. Perhaps the return should be a multi-dimensional array. I don't know but here are the functions I'd like to see:



    Server.getPermissionDetails(GroupName,Node) #Specify the group name and optionally a node. If Node is not specified then the return is a data structure representing the entire yaml file
    Player.getPermissionDetails(Node) #Obviously Group name is not needed. It just returns the effective permissions from the specified node)
    Player.getCustomPermissionDetails(Node) #same as above but the root node defaults to Custom


    Here's an example using what I see the potential to be to centrally store custom settings. These settings and values are arbitrary and not based on any known plugin/script functionality



    so if I wanted to grab a custom setting, we give the parent node and the function returns a JSON (I'm partial to json structures but it could be any other structure that makes sense in Java such as nested arrays(.


    Server.getPermissionDetails("Settler","Custom/AreaProtection")


    this would return something structured like { "GlobalRole": "Settler", "Allowed": { "OpenOthersDoors"}, "Deny" : {"EditAreaWithoutBeingAdded", "OpenOthersChests", "GriefWithTNT"} } (again, this is a JSON example because that's what I'm familiar with)


    or something more specific:


    Player.getCustomPermissionDetails("Guestbook")


    Returns a structure like { "Allow" : { "LeavePublicComent" }, "Deny" : { "LeaveEmailAddress" } }


    Player.getCustomPermissionDetails("Guestbook/Allow")


    this returns something like { "LeavePublicComment"}

    I'll try to summarise (and integrate) the comments I made to my own post quoted above.


    1) Custom permissions can already be added to permissions group files, as long they follow the general syntax (I tried and the server didn't complain). Those custom permissions are simply ignored by the server.


    On this side, there would be nothing to add.


    2) The Player.getPermssionValue(String key) method only returns values for keys it knows about; it does not even return a value for top-level permission properties like "group" or "chatcolor" (it simply returns null). It should return a value for any key actually present in the permission file.


    This should not require a big change in the code, as the permission files are already de-serialised.


    The two steps above should already cover the bulk of @zfoxfire request.
    ____________________


    Then, a few notes:


    A) The current syntax for sub-level keys uses a '_' as level separator (The key customimages:\n enabled: is expressed by the string "customimages_enabled"). This is unusual and may become cumbersome if one of the levels already contains an '_'.


    A different separator( '.', '/', ...) would be better. This is actually rather low priority, though.


    B) The possibility to query for a non-terminal key (for instance, "customimages") and have back a structured object (of whatever kind) is nice, but not so important, IMHO, particularly if this would require to add new code to the server to construct such an object on the fly at each request (I have no idea how permissions are stored internally).


    Also, it would possibly defeat encapsulation: as the object is always returned by reference, any caller could modify it directly, which is probably not wise to allow.


    The ability to query only terminal keys ("customimages/enabled", "customimages/maxupload", ...) would be enough; it would require a few more API calls, but it would also spare (server) code to construct the structured object and (plug-in) code to parse it.


    C) Of major concern: currently plug-ins are completely self-contained in their respective directories; 'polluting' the permission files with plug-in-dependent keys would break this self-containment and risk to leave behind 'dead' values as plug-in are removed or updated.


    D) I am not sure this would actually simplify permission management. For instance, assuming there are 3 plug-ins, each with two permission values, all boolean (a rather conservative assumption); this would require up to 2^6 = 64 permission files to manage all the possibilities.


    Sure, not all possibilities would make sense, but the number of permission files to create, debug and maintain risks to be quite high anyway.


    E) Some convention should be established and enforced to avoid key name clashes; the proposal suggests to group permissions for a plug-in under a top-level key with the name of the plug-in. In fact, even plug-in names risk not to be unique (I think there are already several teleport plug-ins). I have no idea how any chosen convention could be enforced, though.
    ____________________


    Summarising, even if something to simplify the management of plug-in-related permissions could be useful, I am not sure this would be the way to go.

    Thanks @zfoxfire and @Miwarre for sharing your thoughts about the permissions! We need a proper way to add custom permissions for plugins, although I'm not sure if they should be added to the regular permissions folder or if every plugin maintains its own permission file (in the plugin subfolder). I think I need some more time to think about this ;)

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login