Auth API Design and contract questions and concerns

Discuss API design here.
necavi
Developer
Posts: 129
Joined: Wed Jan 30, 2013 9:51 pm

Auth API Design and contract questions and concerns

Postby necavi » Fri Apr 17, 2015 12:39 am

I've been taking a look at the auth API for a while now and have become really curious about the reasoning behind having the three different auth methods (level, permission string/node and flag) exposed at once. That seems like it will only vastly increase the complexity for both the developer and for the end user as some plugins will inevitably use only level, only permission or only flag whereas different auth managers may implement any or all of those, leading to a simple situation where an end user CANNOT load a plugin without loading an additional auth manager. This is in addition to the server operators being, to put it mildly, adverse to added complexity and as they are the target audience for this project, would it not be best to attempt to work towards the simplest solution for them?

Personally I would look towards the bukkit permissions API for inspiration, it is node-based, easy to use and understand: Bukkit Permissible Interface

I would build in supports for auth groups as well, similar to Vault Permission class as a non-required portion of the manager.

Ideally the consumer API would look something like this:

Syntax: Select all

# My current thinking is that only has_permission would have to be implemented, everything else would either return None for get, false for add/remove or whatever the SP devs prefer for API functions
player.has_permission(<permission>) # Could be any string, but a format such as "plugin.commands.slay" would be encouraged to prevent collisions
player.get_permissions() # returns a list containing all of the player's permissions
player.add_permission(<permission>, <save>) # Save would be ignored for managers that do not support saving
player.remove_permission(<permission>, <save>)
player.get_primary_group() # Returns either a group class representing the player's primary group
player.set_primary_group(<groupname or class>, <save>) # Would add the group to the player's group list if it is not already there, then set it to primary
player.add_group(<groupname or class>, save) # Add a group and associated permissions to the player's group list
player.get_groups() # returns a list containing all of the player's groups
player.remove_group(<groupname or class>, save) # Removes a group and associated permissions from the player's group list


A possible concern in a multi-provider environment is which provider to save to? Certainly not all of them, but perhaps the first in the server's provider list? A special config option? The solution here is not obvious and merits some discussion.

Each of these would come with an explicit, documented contract to avoid the confusion that arises from not knowing whether some permissions providers implement some features and others do not. You will be able to know for certain what you can ALWAYS rely on existing, what CAN exist and what CANNOT exist, an important distinction to raise when developing a plugin that requires permissions.


Edit: Slowly making the API here for now until I can get some responses on this.

Return to “API Design”

Who is online

Users browsing this forum: No registered users and 10 guests