LuckPerms | An advanced permissions plugin

Luck · September 4, 2016, 6:32pm

Wildcards are not implemented yet. (Well they were, but I removed it.)

When I do add them, (maybe in the next few days) I intend to implement it in the way that Sponge suggests. See: https://jd.spongepowered.org/4.1.0/org/spongepowered/api/service/permission/PermissionDescription.html#getId--
(In fact, I might be mistaken, it may even be down to the individual plugin to support that?)

I may also implement a way of doing it the legacy Bukkit way, a config option perhaps. I haven’t quite decided yet.

Beauseant · September 13, 2016, 4:38pm

Group based permissions seem to be broken again. No errorlog whatsoever. (just says you have no permission, it was fixed in another build!) Updated to the newest build, and the newest SpongeForge build (BETA 1722) Also, any idea when wildcard gets implemented?

McGangsterFresh · September 14, 2016, 11:27am

@Luck when i try to use commands in game like, /perm creategroup or any other, it shows me the plugin version instead of run the command

Branjazz790 · September 14, 2016, 2:57pm

@Luck is there any wildcard give all permissions node like ‘*’ (which btw for me doesnt work) i remember from bukkit pex that being a thing and i would rather give just 1 wildcard node for the owner/op group than give hundereds, which can get time consuming

SkullTraill · September 14, 2016, 6:07pm

Does this support GriefPrevention?

Luck · September 14, 2016, 6:43pm

@Beauseant Please use the latest build. I’ve fixed most of the issues. Also I’m sorry for the delay with wildcard permissions. I completely forgot to be absolutely honest with you. It’s done now though. Thanks for bearing with me.

@McGangsterFresh Make sure you have permissions to use LuckPerms. Download the latest build, and give yourself “luckperms.*”.

@Branjazz790 Yes. Please use the latest build and ensure “apply-wildcards” is set to true in your config.

@SkullTraill As far as I know, yes. No reason why it wouldn’t work. Again, make sure you’re using the latest build.

(Just a small PSA, there may be some issues with offline mode servers ATM, I’m working on a fix now. )

Thanks for sticking with me. I appreciate this plugin has been nothing but unstable since release, but supporting 3 different platforms and a significant amount of features compared with other plugins isn’t as straight-forward as it may seem.

Hopefully we’re nearing the end of the bugs now. <3

SkullTraill · September 14, 2016, 6:50pm

Ah cool. I just asked because I saw a reply by blood saying you dont use context implementation…

Luck · September 14, 2016, 6:56pm

Yeah, correct. It didn’t have support until 2 weeks or so ago. It should work with the latest builds though.

blood · September 14, 2016, 7:51pm

I did some basic testing using latest SpongeForge 1.10.2 build, GP, and LuckyPerms (B140). Upon entering the game, I attempted to grant permissions to my player via the console. I gave the permissions “luckyperms.user.info” and “luckyperms.info” then attempted to run the following command

/perms user PlayerName info

The only result I got was displaying the LuckyPerms version. Is there something I’m missing? I tested with h2 and yaml storage, both resulted in same thing.

GP also sets up a bunch of default permissions for the default user. I checked luckyperm perm folder and saw no default perms being stored anywhere. Does luckyperms not support a default user?

Also, do wildcards support the following ?
If I grant a player ‘luckyperms’, are you treating it as ‘luckyperms.*’ ?

Thanks

Luck · September 14, 2016, 7:58pm

“luckperms”, not “luckyperms”.

I’m not doing wildcards the Sponge way for LuckPerms commands yet. (on my to-do-list)

As for processing wildcards internally for other plugins, I’m assuming it’s down to the plugin author to support that? I don’t do anything special. It’s not clear from the docs whether it’s down to the service provider to support it, or the plugin. (https://jd.spongepowered.org/4.1.0/org/spongepowered/api/service/permission/PermissionDescription.html#getId--)

LuckPerms also has support for doing it the legacy Bukkit way with “.*” too, if you set the config option to true. (I know you’re trying to defer people from doing this, but there’s a demand for applying wildcards across synced Sponge/Bukkit/Bungee instances of LP)

I’ll do some testing with GriefProtection too.

blood · September 14, 2016, 8:23pm

woops =) OK that worked. However there is still an issue with the default user not being supported from what I tested. If I start my server with PEX, all the default GP permissions are generated correctly but with LuckPerms there is nothing.

As for the code doing this, GP sets up the defaults here

https://github.com/MinecraftPortCentral/GriefPrevention/blob/master/src/me/ryanhamshire/griefprevention/FlatFileDataStore.java#L201

Hope this helps

Luck · September 14, 2016, 8:38pm

There’s some errors in the console thrown regarding getting subjects for “000-000-00… etc” and some random UUID. Perhaps related? Or is PermissionService#getDefaultData being used?

I have no clue about the actual uses of #getDefault or similar methods, I just implemented them as I thought was best.

I see you’re using https://github.com/MinecraftPortCentral/GriefPrevention/blob/master/src/me/ryanhamshire/griefprevention/GriefPrevention.java#L319. Currently that data doesn’t get saved, it’s effectively transient. Should it persist?

Additionally, that default subject is just ignored internally. Seems pretty stupid of me in hindsight, I assume that should be applied to all users? I assume that’s the point you’re making?

Again, I’d be more than happy to sort it, and will make whatever changes necessary, it’s just more a case of understanding what the behavior of those methods should be.

blood · September 14, 2016, 8:45pm

Those UUID’s are both intended to be “fake”. One represents the world user and the other represents the GP Public user. I’m not the only one that uses fake UUID’s, many mods do the same thing for their fake players.

As for default user, yes it should apply to ALL users by default. The code you referenced was actually from 1.8.9, there was a slight change in 1.10

https://github.com/MinecraftPortCentral/GriefPrevention/blob/1.10/src/me/ryanhamshire/griefprevention/GriefPrevention.java#L322

Here is where PEX implements it for reference

github.com

PEXPlugins/PermissionsEx/blob/851c85ac7db397b358a48b8b08332f46e26e577b/permissionsex-sponge/src/main/java/ninja/leaping/permissionsex/sponge/PEXSubjectCollection.java#L127


    }
    return ret.build();
}
/**
 * Get the subject that provides defaults for subjects of this type. This subject is placed at the root of any inheritance tree involving subjects of this type.
 *
 * @return The subject holding defaults
 */
@Override
public Subject getDefaults() {
    return this.defaults;
}
public Optional<CommandSource> getCommandSource(String identifier) {
    final Function<String, Optional<CommandSource>> provider = plugin.getCommandSourceProvider(getIdentifier());
    if (provider != null) {
        return provider.apply(identifier);
    } else {
        return Optional.empty();
    }

And here is an example of what PEX generates for GP’s defaults so you have something to compare against

gist.github.com

https://gist.github.com/bloodmc/ea0c8d5f705d79f0b2b4a76eb0910fd9

permissions.json

{
    "schema-version": 4,
    "subjects": {
        "default": {
            "default": [
                {
                    "contexts": {
                        "localip": "127.0.0.1"
                    },
                    "permissions-default": 0

This file has been truncated. show original

Thanks again for helping me out with support for GriefPrevention =) It will be nice to give users more than one option for a permissions backend.

Luck · September 14, 2016, 9:09pm

Ok, the defaults thing is an easy fix. That’s just me being ignorant.

Still not sure if I should save that default data somewhere? Is it fine to have a blank default subject generated each startup, or should it persist?

The fake UUIDs are harder. I left it out initially for this reason.

https://github.com/lucko/LuckPerms/blob/master/sponge/src/main/java/me/lucko/luckperms/api/sponge/collections/UserCollection.java#L92-L96

My options are:

Have it so fake/offline users are entirely transient. They’ll be created as totally blank users and never saved. (This is what I do at the moment)
Have it so that they are saved. Ok fine, but what happens when they get loaded?
??? I can’t think of another way to do it.

When a user is requested, fake or not, I check the in memory storage and grab a user from there. This works ok, but only for online users.

But… if I were to support getting offline or fake users, then that call would become blocking. Worst case is that I have to query the DB to load the user, best case they’re already loaded.

That method is presumably always called sync, it’s not indicated anywhere that it might take a while to return and should therefore be called async? You’re then blocking the main thread every time a plugin requests an offline user. It’s not so much an issue for PEX where the data is in flatfile, but when you’re querying SQL and then processing that data into an object, that call could take a number of ms.

Again, back to the start, what do I do? I’m probably missing something, lol.

blood · September 14, 2016, 9:50pm

You do not need to worry about handling user lookups when using Sponge. Simply hook into our UserStorageService and we will handle the rest.

https://github.com/SpongePowered/SpongeAPI/blob/bleeding/src/main/java/org/spongepowered/api/service/user/UserStorageService.java

This also supports fake users as we generate a dummy user on our end as well as cache it.

Luck · September 14, 2016, 10:04pm

I mean permission lookups. I have to load permission data for a user when it is requested. All that API seems to do is convert between usernames and UUIDs, and load internal Sponge data.

blood · September 14, 2016, 11:01pm

Oh I misunderstood. So GP doesn’t actually apply permissions to these fake users. So I think transient is fine for now.

Branjazz790 · September 15, 2016, 1:03pm

@Luck i was browsing over the wiki for luckperms and i noticed the part talking about chat configurating. it goes on to say that you need vault to link in the prefixes/suffixes which is of course bukkit and i was quite confused as to how i would allow luckperms to send over prefix/suffix data to something that would handle the actual chat itself using sponge. also i am using nucleus to customise chat if that helps

Luck · September 15, 2016, 3:01pm

Ok perfect. I’ll sort that asap

I’ll look into it

Branjazz790 · September 15, 2016, 3:26pm

ok thanks, i was just pointing this out as with the setup i previously mentioned (luckperms with nucleus handling the prefixes) it wouldn’t show up, but glad you could take a look at it and hope it helps in helping the development of it