Install3 min read
Networks & proxies
How the proxy and backends share one Teho session over signed messages.
There are two supported ways to run Teho on a network. Pick one per network.
| A · Backends only | B · Proxy plugin plus backends | |
|---|---|---|
| Proxy | Nothing installed | TehoAPI-Velocity.jar or TehoAPI-Bungee.jar |
| Backends | TehoAPI.jar | TehoAPI.jar with proxy.secret set |
| Handshake | On every backend join | Once, with the proxy |
| Network features | None | Staff grants, rules, presence and anything set through TehoApi on the proxy |
| Good for | Per-server features only | Networks that want one session and shared staff tools |
A · Backends only
Install TehoAPI.jar on each backend and nothing on the proxy. Each backend runs its own HelloRequest -> Hello -> Welcome when the player arrives. State from the previous backend is cleared by the new Welcome.
B · Proxy plugin plus backends
Install the proxy plugin, then set the same secret everywhere:
proxy:
secret: "a long random string shared by the proxy and every backend"| Where | File |
|---|---|
| Velocity | plugins/tehoapi/config.yml |
| BungeeCord, Waterfall | plugins/TehoAPI/config.yml |
| Paper, Spigot, Folia backends | plugins/TehoAPI/config.yml |
| Minestom backends | TehoMinestom.builder().proxySecret(...) |
Player-info forwarding is required: Velocity modern forwarding or BungeeCord ip_forward. Firewall your backends as usual.
What happens on join
- The client handshakes with the proxy. The proxy answers with a
Welcomethat carries the network'sserver-name. - When the player connects to a backend, the proxy sends that backend a handoff on the
teho:proxychannel: the player's UUID, the negotiated protocol and capabilities, the client'sHellofields and the session id. - The backend creates the session from the handoff, fires
TehoPlayerReadyEventand applies its presets. The client does not handshake again.
What happens on a server switch
- The proxy sends the client a
Reset, which clears the old server's waypoints, HUD and rules. - It then re-sends the network-level state it set itself, such as staff grants, network rules and anything set through
TehoApion the proxy. - If a backend sends its own
Reset, the proxy re-applies its state about 100 ms later.
Client replies still reach backends
Client frames other than Hello, such as consent results, staff tool state, key presses and UI events, are handled on the proxy and also relayed to the current backend inside signed relays. TehoConsentEvent, TehoStaffToolEvent and TehoClientEvent therefore fire on both layers. Frames from a backend to the client pass through the proxy unchanged.
How the proxy channel is secured
- Every
teho:proxymessage is signed with HMAC-SHA256 over a domain prefix plus the body, using your secret. - Messages are bound to the player's UUID, valid for ±30 seconds and single-use, enforced with a nonce replay cache.
- Backends drop any message that fails a check and log the reason at most every 10 seconds.
- The proxy drops any
teho:proxyframe a client tries to send, and ignores aHelloinside a relay, even a chunked one.
Pick one layer per feature
ModuleRules and StaffGrant are full replaces on the client. Let the proxy own network-wide staff tools and rules, and let backends own game features such as waypoints, HUD and notifications. If both layers set rules, the last frame the client received wins.