Access control: Steam authentication and CAMI-based permissions #38

New issue

Open

opened 2026-03-19 09:14:01 +00:00 by kit · 0 comments

kit commented

2026-03-19 09:14:01 +00:00

Owner

Summary

Implement access control for the web spectator client using Steam for authentication and CAMI for permission checks. This controls who can connect, what they can see, and what actions they can perform (once entity editing / RPC is implemented).

Authentication: Steam API

Web clients authenticate via Steam's OpenID or web API to prove their identity (SteamID). This ties each web session to a real Steam account.

Flow

Web client initiates Steam login (OpenID redirect or similar)
On success, client receives a session token tied to their SteamID
Client sends the token on WebSocket handshake
Server-side module validates the token and resolves the SteamID
Connection is accepted or rejected based on permissions

Considerations

Steam Web API key required server-side for token validation
Session tokens should expire and be refreshable
Unauthenticated connections could be allowed in a read-only/spectate-only mode (configurable)

Authorization: CAMI

CAMI is the Common Admin Mod Interface — a standardized Lua API that admin mods (ULX, SAM, Serverguard, etc.) implement. Using CAMI means the permission system works with whatever admin mod the server runs, without hardcoding support for any specific one.

Permission levels (proposed)

webstream_view — Can connect and spectate (view the stream)
webstream_edit — Can modify entity properties (once #32/#36 are implemented)
webstream_admin — Can invoke destructive actions, change server settings

Integration

Register CAMI privileges on module load with sensible defaults (e.g., webstream_view defaults to all authenticated users, webstream_edit defaults to admin)
On WebSocket connect: resolve SteamID → check CAMI.PlayerHasAccess for webstream_view
On property edit / action invoke: check webstream_edit or webstream_admin as appropriate
Server admins configure permissions through their admin mod's UI (ULX menu, SAM panel, etc.) — no custom config needed

Edge cases

Player not on the server: CAMI checks typically require a player entity. For web-only users (not in-game), we may need to fall back to checking the SteamID against stored group membership or a whitelist.
No admin mod installed: Fall back to checking against superadmin/admin usergroups from the default GMod permission system, or allow all authenticated users for webstream_view.

Protocol changes

Handshake message needs a session token field
Server responds with accepted permissions (bitfield or list of granted privileges)
Client UI adapts based on granted permissions (hide edit controls if no webstream_edit)

#32 — Entity property editing (needs webstream_edit permission)
#36 — Lua-defined entity properties and actions (actions need permission checks)

Labels

feature, design

## Summary Implement access control for the web spectator client using Steam for authentication and CAMI for permission checks. This controls who can connect, what they can see, and what actions they can perform (once entity editing / RPC is implemented). ## Authentication: Steam API Web clients authenticate via Steam's OpenID or web API to prove their identity (SteamID). This ties each web session to a real Steam account. ### Flow 1. Web client initiates Steam login (OpenID redirect or similar) 2. On success, client receives a session token tied to their SteamID 3. Client sends the token on WebSocket handshake 4. Server-side module validates the token and resolves the SteamID 5. Connection is accepted or rejected based on permissions ### Considerations - Steam Web API key required server-side for token validation - Session tokens should expire and be refreshable - Unauthenticated connections could be allowed in a read-only/spectate-only mode (configurable) ## Authorization: CAMI [CAMI](https://github.com/glua/CAMI) is the Common Admin Mod Interface — a standardized Lua API that admin mods (ULX, SAM, Serverguard, etc.) implement. Using CAMI means the permission system works with whatever admin mod the server runs, without hardcoding support for any specific one. ### Permission levels (proposed) - **`webstream_view`** — Can connect and spectate (view the stream) - **`webstream_edit`** — Can modify entity properties (once #32/#36 are implemented) - **`webstream_admin`** — Can invoke destructive actions, change server settings ### Integration - Register CAMI privileges on module load with sensible defaults (e.g., `webstream_view` defaults to all authenticated users, `webstream_edit` defaults to admin) - On WebSocket connect: resolve SteamID → check `CAMI.PlayerHasAccess` for `webstream_view` - On property edit / action invoke: check `webstream_edit` or `webstream_admin` as appropriate - Server admins configure permissions through their admin mod's UI (ULX menu, SAM panel, etc.) — no custom config needed ### Edge cases - Player not on the server: CAMI checks typically require a player entity. For web-only users (not in-game), we may need to fall back to checking the SteamID against stored group membership or a whitelist. - No admin mod installed: Fall back to checking against `superadmin`/`admin` usergroups from the default GMod permission system, or allow all authenticated users for `webstream_view`. ## Protocol changes - Handshake message needs a session token field - Server responds with accepted permissions (bitfield or list of granted privileges) - Client UI adapts based on granted permissions (hide edit controls if no `webstream_edit`) ## Related - #32 — Entity property editing (needs `webstream_edit` permission) - #36 — Lua-defined entity properties and actions (actions need permission checks) ## Labels `feature`, `design`

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kit/gmod-web-stream#38

No description provided.

Rows
Columns