How to use Permissions API

Title says it all. How would I use the permissions api to give permissions to people? And PLEASE do not say ‘PermissionsEX is being ported’ or something like that, honestly, I HATE permissionsEX.

I’m with you on that and for sponge, Permissionsex is the only thing that HAS been ported so far. Group manager is still “Being Ported.” I would much rather use GM but they haven’t made any progress in about a month on it :confused:

Are you a developer looking for how to use the API or are you looking for a different permissions plugin?

Permissions plugins provide an implementation for the PermissionService. Internally, Sponge makes a call to that service whenever a permission needs to be checked. Therefore, in order to supply your own permissions, you’ll have to provide a PermissionService implementation yourself that can be configured. If none of the existing PermissionService implementations fit your requirements, you’ll have to create your own.

An example on how the permissions service is called internally can be found in the source code for MixinSubject

I am a developer.

My question NOW is, how would I use that PermissionService to detect whether a user has a perm or not? The naming of the methods seems confusing, sorry if I sound noobish.

You don’t need the PermissionService to test whether a player has a permission. All you need is a Subject to test the permission on (Player implements Subject). Just use Subject.hasPermission().

If you have a Player instance, you can just call Player.hasPermission(String permission). That is the easiest way to check a players permission and you dont necessarily have to deal with the services api

edit: got ninja’ed by @JBYoshi lol

So, I could make a real simple permissions plugin by overriding the hasPermission?

No. You don’t implement hasPermission. Whoever does implement hasPermission should delegate to the PermissionService.

Now i’m confused.

If you are trying to implement a permissions api that works with sponge, there is no “simple” way of doing it. You must implement the PermissionServices class.

If you are just checking to see if a user has a permission, you just need to call Subject.hasPermission() as @JBYoshi mentioned.

What do you mean?

Okay, forget what I just said in the comment about hasPermission.

Sponge uses an interface called Subject as the base for all objects that can have permissions. There are two types of subjects: permissibles and permission holders.

Permissibles are subjects such as Player, who hold permissions but are not specific to a particular permissions plugin. Permissibles simply look up a permission holder and delegate all the Subject methods to it. In your case, you do not write these.

Permission holders are Subjects that are provided by a particular PermissionService and do the real work. In your case, you do write these. However, to be able to provide these to permissibles, you need to write a new PermissionService.

Be aware that Sponge can only have one PermissionService active at a time.

I think I sort of get it… How would I do it?

I’ve never implemented a PermissionService before, so I can’t really help you. You can look at the PermissionsEx source, or you can check out Sponge’s built-in permissions service.

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)

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

Yes, you can add and remove permissions without implementing the PermissionService.
Note that the javadocs for getSubjectData() states:

permissions data that may be persisted if the service provider supports it

So it depends on what the active service is as to whether this persists.

There’s also getTransientSubjectData() which is guaranteed to not persist and is only set for the lifetime of the session