Bridge mode#

A proxy can see connections, chat and commands. It cannot see a player walking, breaking a block or opening a chest — that happens on the game server. Bridge mode is how the two halves cover for each other.

The idea#

Put the same jar on your backend servers. It detects the proxy, drops everything it does not need — no accounts, no database, no license — and does exactly one thing:

Hold every player still until the proxy says they are authenticated.

Turning it on#

Nothing to turn on. A Paper server with proxy forwarding enabled becomes a bridge by itself:

• config/paper-global.yml → proxies.velocity.enabled: true, or
• spigot.yml → settings.bungeecord: true

The console says so at startup:

[slimelogin] Running in BRIDGE mode: this server is behind a proxy, so Slime Login on the
             proxy handles the accounts and this side only holds players until it says they
             are authenticated.

Force it either way with mode: bridge or mode: standalone in config.yml.

How the two sides talk#

Over Minecraft's built-in plugin messaging channel slimelogin:auth, which already exists between a proxy and its backends. No ports, no database credentials, no network configuration.

  Player              Proxy                        Backend (bridge)
    │                    │                                │
    ├── connect ────────►│                                │
    │                    ├── send to lobby ──────────────►│
    │                    │                                ├─ lock (always)
    │                    │◄──── QUERY "is X authenticated?"
    │                    ├──── STATE false ──────────────►│
    │                    │                                │  frozen
    ├── /register ──────►│                                │
    │                    ├─ account created               │
    │                    ├──── STATE true ───────────────►│
    │                    │                                ├─ unlock
    │◄─── free to play ──┴────────────────────────────────┘

Two messages, and each side asks as well as listens:

The backend asks on join (and again a second later); the proxy also pushes the state the moment a player authenticates and on every server switch. Neither side depends on the other's timing.

What gets blocked#

The full set from the standalone plugin, all individually toggleable:

movement · chat · commands · inventory (click, drag, open, drop) · block break · block place · interactions with blocks and entities · damage in both directions · teleport · item pickup · vehicles

protection:
  block-movement: true
  block-chat: true
  block-commands: true
  block-inventory: true
  block-interact: true
  block-break: true
  block-place: true
  block-damage: true
  block-teleport: true
  block-pickup: true
  hide-unlogged: false
  allowed-commands: []

/login and /register are registered on the proxy, so they are intercepted before they ever reach the backend — the player can always run them.

Securing the backend#

Bridge mode trusts the proxy. That trust only holds while players cannot reach the backend directly.

Two things protect it:

1. The proxy filters forged messages. A modified client can send data on any channel. The proxy drops anything arriving on slimelogin:auth from a player, so nobody can tell a backend "I am authenticated" themselves. You will see this in the proxy log if someone tries:

   [Bridge] Dropped a forged auth message from a client.
   

2. Forwarding stops direct connections. Without it, someone who knows the backend's address connects straight to it and never passes through the proxy.

If the plugin cannot confirm a forwarding secret is in use, it says so, loudly:

[Bridge] This server accepts proxy logins WITHOUT a forwarding secret.
[Bridge] Anyone who can reach its port directly bypasses the login system.

On Velocity, fix it with player-info-forwarding-mode = "modern" in velocity.toml plus proxies.velocity.enabled: true and the same secret in config/paper-global.yml.

On BungeeCord there is no shared secret at all — ip_forward: true only passes the player's address along, it does not prove where the connection came from. A firewall that lets nothing but the proxy reach the backend ports is the only real protection there, so the warning stays on until you add one. A BungeeGuard-style plugin does the same job if a firewall is not an option.

Which servers are unprotected#

The proxy notices a backend that never announces itself and names it, once, the first time a player lands there:

Server 'survival' has no Slime Login on it, so players there can move and break blocks
before logging in. Put this same jar in that server's plugins folder - it detects the
proxy and switches to bridge mode on its own.

Nothing is printed for servers that are already covered, so a quiet console means every server a player has visited is protected.

Bridge vs auth server#

Both solve the same problem. They can be combined.