Slime Login

Auth server#

An optional way to hold unauthenticated players on a proxy: send them to a small limbo server and move them to your lobby once they log in.

You probably do not need this

Bridge mode — the same jar on your backend servers — solves the same problem with no extra server and no configuration. The auth server is for networks that already run a limbo, or whose backends are not Paper.

Configuration#

proxy: plugins/slimelogin/config.yml
auth-server:
  enabled: true
  server: "auth"     # a server name from your proxy's configuration
  lobby: "lobby"     # where to send them after they authenticate
velocity.toml
[servers]
auth  = "127.0.0.1:25569"
lobby = "127.0.0.1:25566"
config.yml
servers:
  auth:
    address: 127.0.0.1:25569
  lobby:
    address: 127.0.0.1:25566

Leave lobby empty to keep the player where they are — useful when the auth server is your lobby.

What happens#

  1. Player connects. Their initial server is overridden to auth.
  2. They cannot switch servers (protection.block-server-switch).
  3. They register or log in.
  4. They are moved to lobby automatically.

If the server named in server: is not defined on the proxy, the player is disconnected with the kick-no-auth-server message rather than being dropped somewhere unprotected, and the proxy logs the mistake.

Choosing a limbo#

A standalone jar whose only job is to hold players. Around 30 MB of RAM.

java -Xmx64M -jar NanoLimbo.jar

Set its forwarding mode to MODERN so it works behind Velocity, then add it to [servers] and point auth-server.server at it.

A Paper server with a void world, players in adventure mode and nothing to interact with. Uses more RAM than a dedicated limbo but you already know how to run one.

Put the Slime Login jar on it too — it becomes a bridge and freezes the player as well, which makes it airtight.

Combining with bridge mode#

They complement each other:

Running both means a player waiting to log in is in an empty world and frozen in it.