Documentation Index
Fetch the complete documentation index at: https://v5.rpgjs.dev/llms.txt
Use this file to discover all available pages before exploring further.
Authentication
Use the server engineauth() hook to authenticate a player before RPGJS lets the
WebSocket connection join a room.
In MMORPG mode, RPGJS connects to one room at a time. The first connection
usually targets lobby-*, then map changes reconnect the player to map-*
rooms. The auth() hook is called for each RPGJS room connection. If it throws,
the connection is refused before a RpgPlayer is created or restored in that
room.
Mental model
Useauth() as the global RPGJS gate:
- it runs on the lobby connection;
- it runs again when the player reconnects to a map room;
- it accepts or refuses the room connection;
- it returns the stable public player id used by RPGJS and Signe user collections.
Server
Addauth() to the server engine hooks. Return the stable public player id for
the authenticated account.
publicId used by @users(RpgPlayer).
Return the same id for the same account on every room connection so the player
keeps the same identity when moving between maps.
If auth() returns undefined, RPGJS keeps the default behavior and lets the
room system generate the public player id.
Public lobby, protected maps
If your lobby must stay public, returnundefined for lobby rooms and only
enforce authentication on map rooms:
auth() returns a valid stable player id.
Client
In a browser, send credentials through the connection query. RPGJS sends this query on the initial connection and again when the player reconnects to another room.onConnectError hook:
onConnectError is the place to recover.
The client onConnected hook runs only after the server accepts the RPGJS
connection.
By default, the MMORPG client does not retry a connection that closes before
RPGJS accepts it. This avoids retry loops when a token is invalid. If you need
custom retry behavior, pass PartySocket options through socketOptions:
Guards
auth() is global RPGJS authentication. It decides whether the player may enter
the game and which public id represents the player.
Signe room guards are still useful for more specific authorization rules:
- protect a custom room;
- protect one action;
- protect an HTTP request handler;
- check roles or permissions after authentication.
auth() to identify the player, then use a Signe @Guard() to
restrict an admin action.