[PR #447] [CLOSED] Per-client profile access in ClientSettings #473

New issue

Closed

opened 2026-10-15 13:00:51 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:51 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/447
Author: @kmreisi
Created: 6/24/2026
Status: ❌ Closed

Base: stable ← Head: feature/client-access

📝 Commits (1)

ba46268 feat(api): per-client profile access in ClientSettings

📊 Changes

3 files changed (+14 additions, -1 deletions)

View changed files

📝 src/moonlight-server/api/api.hpp (+2 -0)
📝 src/moonlight-server/api/endpoints.cpp (+6 -1)
📝 src/moonlight-server/state/serialised_config.hpp (+6 -0)

📄 Description

Adds per-client access control to ClientSettings — the existing home for client-specific config (run_uid, controllers_override, motion_controller_override, …).

What

allowed_profiles: vector<string> — profile IDs a client may see and launch. Empty (default) = unrestricted (all profiles).
show_coop_games: bool (default true) — whether a client may see and join other clients' co-op (multi-user) lobbies.

Both are settable over the socket API through PartialClientSettings (the update-client-settings endpoint) and flow through create-lobby, exactly like the existing per-client fields. They show up in the clients response too.

Why

On a shared / multi-tenant host, different clients should see different sets of profiles, and co-op visibility is naturally per-client. ClientSettings is already where per-client policy lives, so this slots in with no new mechanism. Defaults preserve today's behaviour (all profiles visible, co-op visible).

This lets an external UI that drives Wolf over the socket read a client's allowed_profiles / show_coop_games and filter what it shows — without Wolf needing to know anything about that UI.

Draft pending CI.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/447 **Author:** [@kmreisi](https://github.com/kmreisi) **Created:** 6/24/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `feature/client-access` --- ### 📝 Commits (1) - [`ba46268`](https://github.com/games-on-whales/wolf/commit/ba46268e29fb4beab9aeaa2f29d852a865bac419) feat(api): per-client profile access in ClientSettings ### 📊 Changes **3 files changed** (+14 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-server/api/api.hpp` (+2 -0) 📝 `src/moonlight-server/api/endpoints.cpp` (+6 -1) 📝 `src/moonlight-server/state/serialised_config.hpp` (+6 -0) </details> ### 📄 Description Adds per-client access control to `ClientSettings` — the existing home for client-specific config (`run_uid`, `controllers_override`, `motion_controller_override`, …). ## What - `allowed_profiles: vector<string>` — profile IDs a client may see and launch. Empty (default) = unrestricted (all profiles). - `show_coop_games: bool` (default `true`) — whether a client may see and join other clients' co-op (multi-user) lobbies. Both are settable over the socket API through `PartialClientSettings` (the update-client-settings endpoint) and flow through create-lobby, exactly like the existing per-client fields. They show up in the clients response too. ## Why On a shared / multi-tenant host, different clients should see different sets of profiles, and co-op visibility is naturally per-client. `ClientSettings` is already where per-client policy lives, so this slots in with no new mechanism. Defaults preserve today's behaviour (all profiles visible, co-op visible). This lets an external UI that drives Wolf over the socket read a client's `allowed_profiles` / `show_coop_games` and filter what it shows — without Wolf needing to know anything about that UI. Draft pending CI. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:51 +00:00