Data handling issue with LuckPerms

[Eufranio]

I have LuckPerms as permission plugin, and sometimes it doesn't load the permission data when a user logs in, the LuckPerms developed pointed me here.

I tested in a Thermos-1.7.10-B58 environment (currently used for Modded servers, AuthMe-5.3-SNAPSHOT-legacy build 1656 and LuckPerms-Bukkit-Legacy-3.1.29, under a BungeeCord (https://github.com/HexagonMC/BungeeCord) network.

If there's something else I can provide just let me know.

[ljacqu]

and sometimes it doesn't load the permission data when a user logs in

How does that show itself? Is it that even when a player logs in, sometimes (how often?) the player seems to not have any permissions?

[Eufranio]

LuckPerms will NOT load the permissions, and some plugins will throw errors (ofc, the requested data isnt loaded). It happens sometimes, not ALL times, let's say 6 in each 10 logins/players.

They won't have prefixes loaded nor permissions nor displayname and etc.

[sgdc3]

@lucko Hello, do you have any idea why luckperms may conflict with authme? :)

[lucko]

My best guess is UUIDs changing during the login process. No clue if this relates to AuthMe specifically, I just asked @Eufranio if they had any plugins which modified uuids.

I load data on the PreLogin events, store it in a map against UUID, and then check again in Login event to see if the data is still there. If a players uuid changes between the two events, the data isn't present (or rather is mapped to the wrong uuid)

That's just a guess, I'm not sure that's the exact cause. All I know is that these issues only seem to be reported to me from people running cracked servers and hacky plugins to mess with the login process. (FastLogin and the like)

[Malachiel87]

There is also this issue with authme and LP:

• i got 2 server one for login, and if sucesfull it teleport to hub server
• both server have authme reloaded
• I am using luckperms auto-op systerm (op as permission luckperms.autoop)
• when player with this permission login in my hub server he got op permission until authme message appaer "login sucesfull" and then the user will become a normal user without op permission, this don't happen in other server where i don't have authme.

[sgdc3]

@xion87 AuthMe can't handle every possible scenario, auto-op isn't supported by our plugin. The only way to fix that is that LP should listen for our LoginEvent and give the OP only after a successful login.

[sgdc3]

@lucko we don't touch any UUID related stuff, any other ideas?

[sgdc3]

@Eufranio Please provide your plugin list, if you are using FastLogin that could be the cause.

[Eufranio]

When I first tested this, I ran a fresh server with only LP and AuthMe (4 months ago). On my main server, the issue is still present, but with less frequency. I'm running:

Plugins (55): PlaceholderAPI, MagiMarket, ConsoleSpamFix, MagiUtils, MultiWorld, SkinsRestorer, MagiAntiAnimador, MagiKits, BukkitEvaluator, BetterAlias, SimpleAntiAFK, ItemRestrict, LuckPerms, Itemizer, KaisCommons, WorldEdit, UUIDProvider, Skript, OpenInv, Offline_Teleporter, BetterChunkLoader, ClearLag, SkQuery, WorldBorder, BuycraftX, Votifier, ProtocolLib, AutoSaveWorld, VotingPlugin, ForgeRestrictor, Magi-GUI, skUtilities, Vault, FastLogin, HolographicDisplays, WorldGuard, BungeeTabListPlus, CratesPlus, AreaShop, Essentials, GriefPreventionPlus, GPPSkyBlock, Citizens, UltimateChat, DiscordSRV, CutePortals, QuickShop, skRayFall, LeaderHeads, QuickShopWG, EssentialsSpawn, Skellett, AuthMe, TuSKe, AuthMeBridge

[sgdc3]

I think this is FastLogin's fault @games647

[sgdc3]

@Eufranio please open a new issue in the FastLogin tracker, i'm personally using luckperms with authme on my network without any issue.

[games647]

Then it's likely to be related to games647/FastLogin#167

[Malachiel87]

I am not using fastlogin, and in rare case permission don't load (it don't happen only in hub but also in other server, so is not authme fault)

[sgdc3]

@xion87 maybe skinrestorer?

[lucko]

The FastLogin issue linked above was exclusively BungeeCord. I don't think they're related.

Just to clarify:

Plugins which use reflection/some other hack to modify a players unique ID during the login process have the potential to cause serious race conditions and issues with other plugins.

The login process for LuckPerms (and quite a few other plugins looks a bit like this):

AsyncPlayerPreLoginEvent (in theory using any priority)

• Take the given pre-login event, and retrieve the UUID from it.
• Run some database queries to load data for the user.
• Store that queried data in a Map<UUID, Data> somewhere.

PlayerLoginEvent (in theory using any priority)

• Take the given Player, and retrieve the UUID from it.
• Grab the player's data from the map. (issue is only really noticed here)

The issue arises when a plugin modifies the UUID within either the initial pre-login event object or within the Player object via these events. When LuckPerms (or any other plugin) goes to retrieve the data in the PlayerLoginEvent, nothing is there, because the UUID changed.

I don't know enough about FastLogin, SkinRestorer, etc to know which one (if any at all?) is to blame.

As for a fix, I only really know of the approach used by LilyPad, but it's not ideal.

https://github.com/LilyPad/Bukkit-Connect/blob/master/src/main/java/lilypad/bukkit/connect/injector/HandlerListInjector.java

@sgdc3 From what you've said, it's almost certainly not an AuthMe issue, so I apologise for hijacking this issue. 😄

I've added a debug option to LP which should at least confirm that this is the actual issue. https://github.com/lucko/LuckPerms/commit/509826949de1fb40acbece178033dcbb870f5747

@Eufranio I'm happy for you to re-open an issue on the LP tracker until this is resolved.

[games647]

FastLogin on the Bukkit side modifies the UUID before the AsyncPlayerPreLoginEvent by working with the spoofed UUID fields of Spigot and SkinRestorer doesn't need to override the UUID, because it only changes the game profile property of the tablist entry.