Let’s say you have a plugin for giving build permissions for a certain world
/world trust IDragonfire
The plugin doesn’t have it’s own datastore but uses the permission system (makes sense, or not?)
Now someone wants to see who can build in this world:
/world members
So you need a list of all players who have the permission in this world
I realize that for some of you this goes against what the Sponge API should do.
But there’s a reason that Vault became the most downloaded plugin – people thought that this API was useful. Sure it’s not vanilla, but it is extremely useful for at least 80% of server admins.
And there’s a reason it’s layered. That means that plugins can switch out certain layers instead of rewriting the whole infrastructure. To prevent the permissions mess that happened to Bukkit, let permissions plugins only have to worry about individual layers. The point is to give a predictable, standard API between those layers, so the stack can function however server owners want it to function without much pain.
And I’m not even saying that Sponge has to implement the whole stack. Most of us know that once Bukkit had object-level permissions and permissions config storage, the permissions situation was at least somewhat sane. But the point is to have some useful API defaults so that at least the whole thing won’t be implemented over and over. Meaning: have an API skeleton with pluggable layers to adhere to.
I would have suggested to put that in a standard package outside like ‘sponge-perms’ that would be depended on by every permissions plugin, but seeing as there’s been no progress on the package repository I decided to try to get this into core. If there will be a package manager like soak, this package would be a perfect fit. In order to prevent permissions fragmentation once more, this needs to be out at the same time Sponge is, or people will start writing their own implementations.
This is an empty statement. Of course implementation is different, they’re different plugins.
Yes, exactly. Let them choose from SQL vs YML storage, then let them choose between a provider of group-level metadata. This doesn’t mean that the user doesn’t get to customize at all. If anything, it gives the user more combinations that individual permissions plugins didn’t offer before.
@Falkreon and @Minecrell talked about it some hours ago … SpongeCommons
In my opinion we need a new layer, e.g. modules, that build on top of the sponge api that are useful for plugin devs, but not required.
We can use plugins for that, but then we have thousand pieces.
I am not sure, but @sk89q talked about a seperate util package for syntaxsugar.
I think I see where a lot of people are coming from in saying that a permissions API doesn’t belong in Sponge, but I think it’d be more helpful than detrimental. Saying that it’d complicate setup, I’d think not. Bukkit aimed for maintaining a vanilla experience if no plugins/modifications were added, so I think it’d be just as well if the permission API didn’t do anything until told to do so. Personal opinion (and from what I understood from the OP), is that it’d be great if Sponge had a nice cascading permissions API, but didn’t implement it in it’s own server. So it wouldn’t have a permissions file, and it wouldn’t determine who could do what at all, only provide the tools to allow developers to do this early on, rather than writing a nice plugin, then wanting to re-write parts later to fit a user-made permissions API.
I can see how keeping the API vanilla is somewhat of a valid argument, wanting to follow Bukkit’s train of thought (for example, if you want a very vanilla server with only minimal modifications, you don’t want extra functions interfering), but that’s not generally what APIs are for. As the server owner, using Sponge or Bukkit wouldn’t noticeably modify the server unless you wanted it to, unless I’ve misunderstood what Sponge is aiming for.
Not all plugin creators (at least in the Bukkit world) listed all of the permissions used by their plugin. Since I don’t want to OP anyone on my server, I need a complete list of permissions so I can properly enter them into whatever permission plugin I use.
From my experience, it’s usually a bad thing to give people op on the server, as it can give admins access to things that you don’t really want them to have access to like the ability to set perms on other players, which could be a problem if their account was ever compromised in someway.
I also do the same thing with the perms on my server, setup the perms into groups on the server to set to players. I also don’t give the op perms(perm to op ones self, or others.) to any of my admins on my server not even myself, if I need op, I have to set myself as an op through the console.
I think, what can be the best compromise is to implement a very sample groups/permissions manager in Sponge with no extra options. This will be useful for users who want to install a simple server.
But, for me, it is important to have the possibility to override the internal permission system with an external plugin like bPermissions, PermissionEX, zPermissions or … for advanced users who want extra options, like chat prefix/suffix, different permissions in a regions or worlds, etc.
Completely replace external permissions plugin is not a good idea.
I don’t think the OP was asking for in-built permissions, but rather just a system to support checking and managing permissions (so it wouldn’t do anything without a plugin implementing the permissions API to manage permissions)
My intention here wasn’t to describe a spec, it was just a proposal(which seems to have gone 100% ignored by the sponge developers). I specified in my post(word-for-word) that
I don’t know how you got confused thinking that I advocated for sponge to implement SQL persistence unless you didn’t read the post. The main proposal is just to separate the permissions API into layers and not to specify formally how those layers work. The best way to do that is just start creating interfaces.
If the team would like a spec, or if enough people want a spec I’ll write one. There’s already a formally defined wordsmithing spec by the RFC that I would actually use.
I’m inclined to suggest a permissions system like BungeeCord’s, which is basically an event fired for permissions checking and some rudimentary group integration. It seems like the most flexible, and wouldn’t be exceedingly overabstracted like Bukkit’s (sorry sk).
We discussed using an event for permissions checks but decided against it because it allowed more ambiguity over which permissions plugin was providing the permissions service and didn’t allow plugins to update permissions in the service provider’s database.