Promote other user while in-meeting#1482
Draft
lebaudantoine wants to merge 6 commits into
Draft
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| actor=request.user, | ||
| ) | ||
| except RoomRoleError as e: | ||
| return drf_response.Response({"error": str(e)}, status=e.status_code) |
Introduce a new permission class that verifies the caller making a request is both authenticated and actually present in the call. It will be used to gate actions that require the user to be live in the room, for example: * allowing someone in from the waiting room * promoting another participant to a different role More generally, this covers every action where, for security reasons, we need to make sure the user is truly present in the call and that someone is not reusing their cookie as an API key.
Add an endpoint that allows updating a user's role while in a meeting. The goal is to let users promote other connected participants to admin or moderator, so the burden of administrating a meeting can be shared.
lebaudantoine
force-pushed
the
promote-v2
branch
2 times, most recently
from
July 24, 2026 16:45
6f9332a to
5632155
Compare
The backend previously passed an abstract is_admin_or_owner boolean flag in the LiveKit token. That kept the frontend minimalistic and saved it from having to handle role comparisons. As we introduce more features that need to distinguish between the room owner and admins, refactor the token to carry the role directly. The frontend can then derive the relevant flags from a richer piece of information.
Include the is_authenticated flag on the user in the LiveKit token and participant metadata. The frontend needs this information (used in the next commit) to know whether it can offer to promote a user with access to the room admin.
Add the frontend client that calls the update participant role endpoint. Straightforward API call, no special handling.
The is_administrable flag was previously read from the room API response through the room serializer, giving the frontend static information about the user's rights. Refactor the frontend so it derives this flag from the participant role carried in the participant metadata instead. Two benefits: * The flag now updates live along with the participant attributes/metadata, so role changes are reflected immediately. * It removes the duplication between the API response and the metadata, which both used to determine the user's capabilities.
lebaudantoine
force-pushed
the
promote-v2
branch
from
July 24, 2026 22:03
5632155 to
0a2c4ce
Compare
|
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
2 participants
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.
No description provided.