mirror of
https://github.com/suitenumerique/meet.git
synced 2026-09-02 05:38:02 +00:00
✨(backend) let any authenticated user manage the lobby on trusted rooms
On rooms with the `trusted` access level, any authenticated user connected to the meeting can now manage the lobby. Requested by several organizations, and a step toward generalized lobby management once hubs and groups land (same organization only). Being authenticated is not enough to grant the capability: a `trusted` room means "trusted to join", not "trusted to decide who else joins from outside the call". The new `CanManageLobby` permission therefore also requires the requester to be currently connected to the meeting, verified against LiveKit and failing closed, like `IsPresentInMeeting`. The access level itself is never cached and always read fresh, so an owner switching the room back to `restricted` revokes the capability on the very next request - the one guarantee we did not want to trade for performance. Performance is traded elsewhere: the waiting list is polled by every lobby manager, and on a trusted room that audience grows from a few admins to potentially the whole meeting. Hitting LiveKit once per poll per participant would not survive that fan-out, so presence is memoized in Redis (`PresenceCache`, `PRESENCE_CACHE_TIMEOUT`, 1h). Entries are created lazily because only the minority of participants who actually manage a lobby ever need one, and only positive answers are cached because a sticky negative would lock out someone joining right after a miss for the whole TTL. Eager invalidation on `participant_left`, `room_finished` and admin kick keeps the cache honest; the TTL is the safety net when an event is lost, and its value bounds how long a departed participant could still act. Trade-offs in this v0: * `PRESENCE_CLEAR_ON_PARTICIPANT_LEFT` gates the eager invalidation on `participant_left`: its cost is one Redis DELETE per departure, for every departure, so we want to be able to measure it in production and turn it off independently of the feature. When disabled, invalidation relies on `room_finished` and the TTL only, widening the stale window above. * This can put non-trivial pressure on the cache at scale; the rollout will need to be monitored closely. * The `participant_left` webhook must be enabled in the LiveKit deployment, otherwise eager invalidation silently degrades to the TTL-only behavior.
This commit is contained in:
committed by
aleb_the_flash
parent
c02d54b6ff
commit
7369379106
@@ -5,7 +5,7 @@ from django.http import Http404
|
||||
|
||||
from rest_framework import permissions
|
||||
|
||||
from ..models import RoleChoices
|
||||
from ..models import RoleChoices, RoomAccessLevel
|
||||
from ..services.participants_management import (
|
||||
ParticipantNotFoundException,
|
||||
ParticipantsManagement,
|
||||
@@ -198,3 +198,48 @@ class IsPresentInMeeting(permissions.BasePermission):
|
||||
return False
|
||||
except ParticipantsManagementException:
|
||||
return False
|
||||
|
||||
|
||||
class CanManageLobby(permissions.BasePermission):
|
||||
"""Grant lobby management (list/accept/deny waiting participants).
|
||||
|
||||
- Room admins/owners can always manage the lobby.
|
||||
- When the room access level is TRUSTED, any authenticated user who is
|
||||
currently connected to the meeting can manage the lobby. Presence is
|
||||
verified cache-first (Redis), falling back to the LiveKit API.
|
||||
|
||||
Access level is always read fresh from the DB; only presence is cached,
|
||||
so changing the room to RESTRICTED takes effect immediately.
|
||||
"""
|
||||
|
||||
message = "You are not allowed to manage this room's lobby."
|
||||
|
||||
# pylint: disable=too-many-return-statements
|
||||
def has_object_permission(self, request, view, obj): # noqa: PLR0911
|
||||
"""Check privileges first, then the trusted-room presence path."""
|
||||
user = request.user
|
||||
|
||||
if not user or not user.is_authenticated:
|
||||
return False
|
||||
|
||||
# Product choice: lobby management is reserved for session-authenticated
|
||||
# users with a real account, not holders of a LiveKit room token.
|
||||
if request.auth and hasattr(request.auth, "video"):
|
||||
return False
|
||||
|
||||
if obj.is_administrator_or_owner(user):
|
||||
return True
|
||||
|
||||
if obj.access_level != RoomAccessLevel.TRUSTED:
|
||||
return False
|
||||
|
||||
self.message = "You must be connected to the meeting to manage its lobby."
|
||||
|
||||
try:
|
||||
return ParticipantsManagement().check_if_in_meeting_cached(
|
||||
room_name=str(obj.pk), identity=str(user.sub)
|
||||
)
|
||||
except ParticipantNotFoundException:
|
||||
return False
|
||||
except ParticipantsManagementException:
|
||||
return False
|
||||
|
||||
Reference in New Issue
Block a user