feat(avatars): persist player avatars beyond room sleep + website ava…#51
Merged
Conversation
…tars Avatars previously lived only on live client connections (profile_data over the socket) and were never rendered on the web, so they went useless once a room slept. This makes the avatar a durable, web-session-linked attribute that survives until the room is pruned, settable from the website, and able to flow into the desktop client. Four logical parts: 1. Website avatar (per web session): new SessionAvatar table + cookie-authed /me/avatar upload/remove, reusing the avatar.py pipeline via a per-session AvatarToken (no schema change to the existing avatar tables). Nav avatar wired through a context processor. 2. Tracker rendering: new SlotAvatar table + per-slot resolution (explicit web-set > client-set profile_data, honored only when HTTPS on the trusted-host allowlist > the slot's lobby player's session avatar). /api/tracker gains player_avatars; the multitracker and per-player tracker render avatars; a rate-limited, non-exclusive "set avatar" control lives on the per-player tracker. This is what makes avatars visible on the web and persist through sleep. 3. Live-server bridge: customserver seeds profile_data from web-set SlotAvatars at boot (denormalized avatar_url, best-effort) so connected desktop clients render them too. 4. mwgg:// deep-link: MultiWorld.py now accepts the protocol URL (the flags-only parser previously rejected it) and persists last_server_hostname/port/username + the gated avatar before the GUI starts, so the launcher opens pre-filled with the room and the player's website avatar. macros.html carries &avatar=; CommonClient gains parse_connect_url and safe_avatar_source. Web and client render both honor the same trusted-host allowlist (multiworld.gg, mw.prismativerse.com), mirroring mwgg_gui.safe_avatar_source. Tests: test/webhost/test_session_avatar.py, test_slot_avatar.py, test/general/test_connect_url.py; full webhost suite green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…tars
Avatars previously lived only on live client connections (profile_data over the socket) and were never rendered on the web, so they went useless once a room slept. This makes the avatar a durable, web-session-linked attribute that survives until the room is pruned, settable from the website, and able to flow into the desktop client. Four logical parts:
Website avatar (per web session): new SessionAvatar table + cookie-authed /me/avatar upload/remove, reusing the avatar.py pipeline via a per-session AvatarToken (no schema change to the existing avatar tables). Nav avatar wired through a context processor.
Tracker rendering: new SlotAvatar table + per-slot resolution (explicit web-set > client-set profile_data, honored only when HTTPS on the trusted-host allowlist > the slot's lobby player's session avatar). /api/tracker gains player_avatars; the multitracker and per-player tracker render avatars; a rate-limited, non-exclusive "set avatar" control lives on the per-player tracker. This is what makes avatars visible on the web and persist through sleep.
Live-server bridge: customserver seeds profile_data from web-set SlotAvatars at boot (denormalized avatar_url, best-effort) so connected desktop clients render them too.
mwgg:// deep-link: MultiWorld.py now accepts the protocol URL (the flags-only parser previously rejected it) and persists last_server_hostname/port/username + the gated avatar before the GUI starts, so the launcher opens pre-filled with the room and the player's website avatar. macros.html carries &avatar=; CommonClient gains parse_connect_url and safe_avatar_source.
Web and client render both honor the same trusted-host allowlist (multiworld.gg, mw.prismativerse.com), mirroring mwgg_gui.safe_avatar_source.
Tests: test/webhost/test_session_avatar.py, test_slot_avatar.py, test/general/test_connect_url.py; full webhost suite green.
Please format your title with what portion of the project this pull request is
targeting and what it's changing.