This repository was archived by the owner on Jul 10, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Understanding session registry
Ian Castaño edited this page Aug 21, 2020
·
1 revision
The SessionRegistry is a way to know all the pertinent data of the connection of a user to know if he is online, authenticated, his version, etc...
This registry is stored in Redis from the moment he reaches the authentication server until the moment he leave the BungeeCord Proxy.
Note: Remember that this registry totally differs from the model that stores user data. This only works so that Minecraft can keep track of who is online and who is not.
- The session must be altered only three times during all its lifecycle. One for
Creation, one forAuthorizingand one forDeletion. - The session should only be created when the user joins an authentication server.
- Registered data should never be manually modified or manipulated by any class other than the
SessionRegistryManager. - There should only be one session related to a user. Any other attempt to create a session while there is an existing one must be COMPLETELY canceled.
- As long as the session has not been authenticated, the user must not be able to enter any server other than authentication.
- When joining each server, you must check if the player's IP matches the registry's IP. If it doesn't, the user must be kicked from the proxy and being forced to authenticate again. No exceptions.
Understanding this, we are going to proceed to configure a basic authentication server.
- Understanding Session Registry
- Configuring a server
- Authentication Gateways
- Invalid Auth & Cooldowns
- Introduction
- Matchmaking
- Server Pairing
- Match Scheduling
- Lobby Functionality
- Stats
- Match Event Handling