Error dispatching event PermissionCheckEvent
dinfyru opened this issue ยท 10 comments
Bungee - 1451
LuckPerms - 5.0.63
storage-method: PostgreSQL
messaging-service: redis
auto-push-updates: true
The error went away only after entering the networksync command.
21:14:30 [WARNING] Error dispatching event PermissionCheckEvent(sender=RUSROBOTX, permission=bungeecord.command.server, hasPermission=false) to listener me.lucko.luckperms.bungee.listeners.BungeePermissionCheckListener@1e044120
java.lang.IllegalStateException: No permissions data present for player: RUSROBOTX - 1910ec38-e9fb-44c9-be61-1ac67c84e7c0
at me.lucko.luckperms.bungee.listeners.BungeePermissionCheckListener.onPlayerPermissionCheck(BungeePermissionCheckListener.java:65)
at jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at net.md_5.bungee.event.EventHandlerMethod.invoke(EventHandlerMethod.java:19)
at net.md_5.bungee.event.EventBus.post(EventBus.java:46)
at net.md_5.bungee.api.plugin.PluginManager.callEvent(PluginManager.java:400)
at net.md_5.bungee.UserConnection.hasPermission(UserConnection.java:546)
at net.md_5.bungee.api.plugin.Command.hasPermission(Command.java:63)
at net.md_5.bungee.api.plugin.PluginManager.dispatchCommand(PluginManager.java:171)
at net.md_5.bungee.api.plugin.PluginManager.dispatchCommand(PluginManager.java:142)
at net.md_5.bungee.connection.UpstreamBridge.handle(UpstreamBridge.java:145)
at net.md_5.bungee.protocol.packet.Chat.handle(Chat.java:50)
at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:104)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:321)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:295)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Thread.java:834)
We would need additional information.
- What is the Bungee version (the MC version, not build number)
- LP config (Remove username and password from the login cridentials before sharing (preferably through https://hasteb.in))
Bungee version 1.15.2 (build 1451)
https://pastebin.com/vGph2G37
One more error
[16:45:30 WARN]: [LuckPerms] LuckPerms already has data for player 'Jakubson' - but this data is stored under a different UUID.
[16:45:30 WARN]: [LuckPerms] 'Jakubson' has previously used the unique ids [5ea61e81-30c1-4c2e-84c8-776010fb95c0] but is now connecting with '520068b1-e9a8-4679-bf50-6ba37df55eb5'
[16:45:30 WARN]: [LuckPerms] The UUID the player is connecting with now is Mojang-assigned (type 4). This implies that one of the other servers in your network is not authenticating correctly.
[16:45:30 WARN]: [LuckPerms] If you're using BungeeCord/Velocity, please ensure that IP-Forwarding is setup correctly on all of your backend servers!
[16:45:30 WARN]: [LuckPerms] See here for more info: https://github.com/lucko/LuckPerms/wiki/Network-Installation#pre-setup
[16:45:30 INFO]: UUID of player Jakubson is 520068b1-e9a8-4679-bf50-6ba37df55eb5
[16:45:30 INFO]: Jakubson[/93.105.177.76:50429] logged in with entity id 24 at ([world]136.94974849276716, 11.0, 164.8414929273983)
The error tells you exactly what is wrong:
LuckPerms already has data for player 'Jakubson' - but this data is stored under a different UUID.
The user has a different UUID than when he joined last time, meaning that something is different this time.
The most common issue is, that ip-forwarding was not properly setup, or that the user joined directly to the server, rather than through the proxy.
@Andre601
For authorization, I use the jpremium plugin. It assigns a unique new generated uuid to the user. And during authorization, the same uuid is always shown. However, luckperms sometimes throws such an error. It does not always happen randomly. https://github.com/Jakubson/JPremium/wiki/Frequently-asked-questions#what-is-fixed-unique-id
After clear install
Full logs https://pastebin.com/xHCysa5K
I put together a completely new build without plugins. Installed only jpremium and luckperms. New databases. The situation is similar.
Then perhaps your jpremium plugin is the cause?
Since you use this do I assume that your network is running in offline mode.
In this case is the fact that the UUID might be different a normal thing as UUIDs work differently than in online mode.
This is all I can (and will) tell you as I'm not really interested in helping with a cracked (offline mode) server. Sorry for that.
Issue is likely being caused by JPremium.
LuckPerms uses UUIDs to uniquely identify players (I mean duh that's the point of them). If plugins (JPremium) are randomly changing players uuids, or modifying them in an unsafe manner on login then it should be expected that other plugins and systems will not work properly.
Not much I can do - I suggest reporting the issue to JPremium's author.