Documentation

Support

Lobby

Lobby

Access control

Configure visibility and access permissions to control who can discover and join your lobbies.
Read time 1 minuteLast updated 14 hours ago
By default, Lobby accepts API calls from either an Authenticated Player or a Service Account. In some cases, you might want more control over how lobbies are created or joined. In those cases you can use Access Control.

Service Account controlled lobbies

In the following example, lobbies can only be created and players can only join via a Service Account. This allows you to control the lobby by restricting write access for Players. Creating project policies via CLI with the following JSON definition will 
Deny
all write access to Lobby service APIs, except the Reconnect, Heartbeat and Tokens endpoints. Note that any API that requires read access (HTTP GETs) will still be accessible. 
{  "statements": [    {      "Sid": "DenyLobbyServiceWrite",      "Resource": "urn:ugs:lobby:/v1/*",      "Principal": "Player",      "Action": ["Write"],      "Effect": "Deny"    },    {      "Sid": "AllowLobbyServiceReconnect",      "Resource": "urn:ugs:lobby:/v1/*/reconnect",      "Principal": "Player",      "Action": ["*"],      "Effect": "Allow"    },    {      "Sid": "AllowLobbyServiceHeartbeat",      "Resource": "urn:ugs:lobby:/v1/*/heartbeat",      "Principal": "Player",      "Action": ["*"],      "Effect": "Allow"    },    {      "Sid": "AllowLobbyServiceTokens",      "Resource": "urn:ugs:lobby:/v1/*/tokens",      "Principal": "Player",      "Action": ["*"],      "Effect": "Allow"    }  ]}
Upsert the policies with 
ugs access upsert-project-policy -p <project-id> -e <env-name> <file-path>
. At this point, any API call that violates the policy will be rejected with a 
403 - Forbidden
error.