Minecraftforge: Event Request: Handle Login

[DeliciousJaffa]

I've looked through quite a few classes and can't find a way to hook in simply for a whitelist mod.

What I'm requesting is a post-auth and pre-login event that provides either the profile or network handler with the ability to set the result to deny or cancel the event.

[PaleoCrafter]

Uhm... just use PlayerEvent.PlayerLoggedInEvent and kick the user again if they're not allowed to join?

[AEnterprise]

isn't that what the build in whitelist is ment for?

[DeliciousJaffa]

@AEnterprise I fetch JSON from my own site which is firing off requests to some APIs and such which is intended to allow someone to link their account using my service once and access any server where certain conditions are true.

@PaleoCrafter That event is post-login and allows the user to login briefly. (Player joined and leave show up in the console/chat too).

[DeliciousJaffa]

Here is a sample of how I utilise a similar event to what I'm requesting in my bukkit plugin version.
https://github.com/DeliciousJaffa/MultiTwitchWhitelist-plugin/blob/master/src/cat/jaffa/multitwitchwhitelist/LoginListener.java#L112

[TechnicianLP]

• At the time PlayerEvent.PlayerLoggedInEvent is called the server already created files for that player - therefore disconnecting them earlier is preferable
• Just using EventResult has the problems of different mods setting it to ALLOW/DENY(instead of DEFAULT) at the same time -> raceconditions
• If this Event does get implemented a way to conditionally bypass the default-verification (if for example auth-servers are down and the mod can provide a different method of authenticating the player)
• Therefore i suggest a hook in NetHandlerLoginServer.processEncryptionResponse replacing the UserAuthentificator-Thread which would fire after a modified variant of the default Thread completed in order to allow eventsubscribers to both:
  
  
  
  • Use a custom way of authentificating a otherwise rejected Player (as described above)
  
  
  • Disconnect any Player at the GameProfile stage (custom disconnect method that also cancels the event)
  
  
  • EventPriority can be used to "indicate" wether you authentificate or depend on authentification (execution order)
  
  
  • if any subscriber or vanilla accepts the player and he did not get disconnected the LoginState gets set to READY_TO_ACCEPT
  
  

[Cloudhunter]

I'll point out form my own investigations that kicking someone from the PlayerLoggedIn event doesn't result in the message being sent to the client, so current ways of denying login are insufficient as the user has no idea why they can't connect.

True, you could delay the kicking until a later event, but you run the risk of users being able to send packets and otherwise interact with the world if you do so, so some way of declining it early on like suggested above would be appreciated.

[DeliciousJaffa]

There is a method that the vanilla server uses to check whitelisting, ban lists and all, it seems forge could quite easily use it to provide the requested functionality. The vanilla method simply uses a String return for a message to send to the client or null to signify the login should continue.

=== MC 1.12: net/minecraft/server/management/PlayerList.allowUserToConnect (pj.a) UNLOCKED ===
Name       : a => func_148542_a => allowUserToConnect
Descriptor : (Ljava/net/SocketAddress;Lcom/mojang/authlib/GameProfile;)Ljava/lang/String;
Comment    : checks ban-lists, then white-lists, then space for the server. Returns null on success, or an error message
SRG Params : SocketAddress p_148542_1_, GameProfile p_148542_2_
MCP Params : SocketAddress address, GameProfile profile

[TechnicianLP]

While a hook in PlayerList.allowUserToConnect would allow to disconnect players it would lock down the usecase to just that instead of also allowing to accept rejected players

[DeliciousJaffa]

Not necessarily, Hooks for the event could be processed first before a result is delivered.
Is that not how events currently work anyway?

[TechnicianLP]

the check to that method is done in NHLS.tryAcceptPlayer() which is only called if the currentLoginState is READY_TO_ACCEPT which only gets set if the default authentification is successfull (and i just realized that the hook can't be placed in processEncryptionResponse either because it would not fire if the server is in offline-mode)

[DeliciousJaffa]

Which it should be called after. If you want to skip authentication simply set offline-mode to true on the server.

[TechnicianLP]

Skipping authentication completely does not cover implementing a fallback authentication-method (which is what im after)
But due to the two completly seperate usecases of a LoginEvent it's probably better to split them into a PlayerAuthentificationEvent and a PlayerConnectingEvent

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[TechnicianLP]

This issue is still not resolved (even though not really active either)

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

[phit]

This is still very much needed, any chance this can be reopened and looked at? There was even a PR at some point..