Questions about how to implement a Permissions Service

[Blossomforth]

Hello

I am working on creating a permission system and I would like to have a few questions answered, if at all possible.

First and foremost, I have read these threads and to be honest, I feel as though I have made little progress on my understanding of what is required in order to create a permission service.

When implementing PermissionService, a bunch of methods are required, requiring you to do things (such as newDescriptionBuilder, requiring you to return a Builder), Others require you to return specific objects, such as a SubjectCollection (I’m not sure what this is).

The PermissionDescription is kind of confusing, and I’m hoping these are just misconceptions, but if the User/Staff/Admin permissions are in the Permission Description interface, why are we required to use it, or rather, how do we change it? Its an interface required by the base permission interface, so why does it have default classes that are members, which means they cannot be removed. Again, I’m really hoping that I am just not understanding what I am seeing.

I’ve looked through the PermissionsEx source, but honestly its a mess, and I cant really make heads or tails on what is going on in there. Would someone please help me figure this out? I’ve been staring at source code for a few hours now

[Socratic_Phoenix]

@Blossomforth
You don’t necessarily need to implement a Permission Service to create a permissions system, although if you want to do anything too complex you might need to.

Because of the default implementation, it is possible to add/remove permissions from players without implementing anything, all you need is a SubjectData, which can be obtained through a Subject. There are two kinds of SubjectData, normal and transient. Normal data may or may not be persistent over server restarts (depends on implementation - pretty sure default one doesn’t save anything). Transient data is never persistent over server restarts.

Now, if you want to mess with contexts and the internals of the Permission Service, you may want to implement it, but I’ve found it easier just to give and add permissions.

Like I said in one of those threads you read:

@meguy26

@Kitteh SubjectData has a method for setting permissions - I’m not particularly sure exactly how Sponge handles this, but from my tests it appears to work okay.

Subject has the method getSubjectData(), so therefore so does player.

EDIT: Also, Subject has the method getActiveContexts(), which can be used as the Set parameter for the set method (I think)

@simon816 Will this work if we want to give/remove permissions from a player without implementing our own PermissionService?

[Blossomforth]

Hmm, I see. Would this type of setting of the permissions not work if the default permissions system for sponge was replaced, do you know?

Anyways, Thanks for the info! This will have to do until the documentation for the permission service is fully documented I know that i could do a lot of cool things if i could only understand the permission service API.

[Socratic_Phoenix]

This way of setting permissions really shouldn’t break, even if the default system is replaced. The only thing that might change is whether or not non-transient SubjectData is saved or not.

[Blossomforth]

Hmm. I have to wonder, then, why at all is this permissions service changeable then? :\

[Socratic_Phoenix]

I don’t think the default implementation deals with contexts or anything above setting/removing permissions. In addition, it allows for plugins like PermissionsEx, which during the Bukkit ages used reflection to kill Bukkit’s perm system, to simply integrate into the api seamlessly.

[Blossomforth]

@meguy26

Because of the default implementation, it is possible to add/remove permissions from players without implementing anything, all you need is a SubjectData, which can be obtained through a Subject.

Okay, so I’ve gotten the SubjectData, and theres a setPermission method here, but its requesting a set of contexts, a string (the permission, i presume), and then a tristate, of which i’m assuming is the value i need to set the permission to.

Lets say that I want to just simply set a permission as true or false, am i required to provide a set of contexts? Should i be setting the first parameter to null or an empty set or something?

@meguy26

I don’t think the default implementation deals with contexts or anything above setting/removing permissions. In addition, it allows for plugins like PermissionsEx, which during the Bukkit ages used reflection to kill Bukkit’s perm system, to simply integrate into the api seamlessly.

Ah, okay yeah this makes sense. I remember all the problems PEX created in bukkit, haha. To be honest, It was the reason why i developed my own permissions system back in those days.

[Socratic_Phoenix]

If you don’t want to mess with Contexts, just fill that parameter with either an empty set, or SubjectData#getActiveContexts(). The second one is probably more reliable, but it really depends on the implementation, the default one should really do fine under either solution.