TCPShield overwrites the IP address during connection. ProtocolLib
doesn't notice this change, because it uses the end-to-end connection
which is the proxy IP. This causes getAddress calls during Spigot play
state and ProtocolLib auth state not match and then have conflicting
session ids.
A solution is also to hold onto the temporary player object. However
since we don't get a notification for a disconnect, holding it will
prevent to get GCed until the timeout occurs (1 minute).
Fixes#595
If we disable filters, other plugins are advised to only monitor
packets. Potential modifications can be allowed by enabling the filtering again, but adding our meta data to prevent duplicate
processing.
Previously: If allowFloodgateNameConflict = false or linked and either autoLoginFloodgate or
autoRegisterFloodgate is set to no-conflict and a player with a non-conflicting name
connects then there will be a double check.
Referencing 'FloodgatePlayer' in JoinManagement.java and it's subclasses
has cause ProtocolLib to fail to register an event when Floodgate was not
installed.
If I ever tried to either cast or use FloodgatePlayer as a return type
when Floodgate was not installed in the server, I got this error:
[19:37:46 ERROR]: [FastLogin] Plugin FastLogin v1.11-SNAPSHOT-744264d has failed to
register events for class
com.github.games647.fastlogin.bukkit.listener.protocolsupport.ProtocolSupportListener
because org/geysermc/floodgate/api/player/FloodgatePlayer does not exist.
ProtocolLib doen't have this problem.
Added a shared class for Floodgate name conflict checking that can be used by both ProtocolLib and ProtocolSupport
Rebased on Sat May 22 11:42:08 2021 +0200
Added access modifier to "FastLoginBukkit plugin;" in FloodgateHook.java
Rebased on Sat May 22 11:42:08 2021 +0200
Initialize FloogateHook in ProtocolLib's class
Floodgate 1.0 does not work with the current Bukkit implementation.
ProtocolLib and Floodgate don' play along nicely when used with FastLogin
Related issue: #493
The FloodgateApi is the same for Bukkit and Bungee, so the Floodgate
related code could be used in a future Bungee implementation too.
Currently, Bungee will report Floodgate disabled to core, so the
upstream Floodgate implementation will be used there.
If enough code will be moved to core, I might consider enabling these
features to BungeeCord too.
