Each recording start writes a Recording row and spins up a recording
worker, so a user or buggy client hammering the endpoint is costly even
when the calls end in a conflict or a worker failure.
Throttle it per authenticated user, mirroring room creation: a short-term
limit of 10/minute absorbs bursts and a daily cap of 100/day bounds
sustained use. Both are configurable via START_RECORDING_THROTTLE_RATES
and START_RECORDING_DAILY_THROTTLE_RATES.
Only starting a recording is throttled, as it is the costly action.
Stopping a recording only releases resources, so it is left unthrottled
and a throttled user can always stop an ongoing recording.
Trace the login flow of the embedded iframe frontend flow.
An application minting a transit code for its delegated user should
logs the transit_code issuance and it's exchange for a user access
token. The transit_code can be identified and with a
SHA-256 to audit eventual replay attacks.
Emit audit events across the recording lifecycle: recording.start,
recording.stop and recording.delete from the API, recording.end when
LiveKit reports the egress ended, recording.transcript.request when the
backend sends a recording to the summary service, and
recording.transcript.report and recording.summary.report when that
service calls back.
recording.end has an unknown outcome when LiveKit reports an egress
status the backend does not map, and recording.transcript.request names
the summary service as service.target.
Small bugfix: AuditViewMixin keeps a copy of a deleted target, since deleting an
instance clears its primary key.
Any authenticated participant can now start a recording on trusted
and public rooms. This is essential, requested by many users, and
should encourage people to authenticate on public rooms. It also
means the starter may hold no role on the room, so who gets access
to the recording has to be decided explicitly.
The part open to discussion is the recording access: who should be
owner/admin on the recording. This commit picks the simplest
design:
* The room's owners and administrators get an `OWNER`
`RecordingAccess`: they can retrieve, download, stop and delete
the recording.
* The starter gets a `MEMBER` `RecordingAccess`, unless they already
own or administer the room, in which case they get `OWNER`. A
member can retrieve and download the recording but cannot delete
it: deletion is irreversible and affects everyone with access, so
it stays with the people responsible for the room.
* Everyone with an access, members included, receives the
"recording ready" email.
* Room roles are copied when the recording starts: later changes
to the room's accesses do not affect existing recordings.
The people responsible for a meeting should control its recording
and transcript, and whoever initiated it should be able to access
it on their own. The starter owns the output and is responsible for
sharing it with their colleagues.
Recording members could not retrieve a recording before this
commit. No code path created such accesses until now, but one added
manually through the admin now grants read access.
One constraint is respected: the summary service creates a doc,
and the docs API can only attribute it to a single owner. The
summary therefore goes to the oldest access, and the starter's
access is created before the room owners/admins ones, so the
starter receives it. The lookup does not filter on role, since the
starter may only be a member. The previous lookup took `.first()`
with the default newest-first ordering, which with several owners
would have picked a room admin.
Alternatives considered:
* Granting access to every participant allowed to record, or to
those present when the recording starts: it requires listing
participants from LiveKit and creating an access for each, and
widens access by default, for a need no user has expressed.
* A `creator` attribute on the recording row: it only adds a
migration without adding value to access control, so it was
dropped.
* Restricting access to the link owner even when someone else
starts the recording: some organizations may want this for
security reasons, but it is YAGNI until a few large clients ask
for it.
I think we should contribute to Docs' api to allow sharing the
transcription document with several users.
Before this commit, a room update and a soft deletion racing each other
could leave the room active.
Both `perform_update`s now re-read the room with `SELECT ... FOR UPDATE`
inside a transaction to avoid this race condition.
Before this commit:
1. Rooms could be hard-deleted from the internal API (unused by the
frontend).
2. The external API had no way to delete a room.
3. The admin could hard-delete rooms.
What this commit does:
1. Add a `deleted_at` field to Room. `Room.objects` hides soft-deleted
rooms; `all_objects` stays the default manager so deleted rooms keep
reserving their slug and PIN code.
2. Soft delete rooms from the internal API (replacing hard delete) and
the external API (new DELETE, owner only, `rooms:delete` scope). The
LiveKit room is closed and its participants disconnected; if closing
fails, the soft delete is rolled back and an error is returned.
3. Answer 410 Gone on detail operations on a deleted room (after
permission checks). Its can still be read but not modified.
4. Close LiveKit rooms recreated after deletion by participants still
holding a valid token (room_started webhook).
5. Frontend: participants in the call land on the feedback page without
the rejoin button, lobby participants see a "meeting deleted" screen,
and opening the link shows an error instead of recreating the room.
Untouched by this commit:
- The admin still hard-deletes rooms, without closing the LiveKit room,
and lists soft-deleted rooms alongside active ones.
- Purging soft-deleted rooms (hard deletion) is not handled.
- Scheduled deletion is not handled.
The participant id returned by request-entry was the raw LiveKit UUID,
so anyone knowing it could poll the lobby and obtain the admitted
participant's LiveKit token.
Return the id signed with SECRET_KEY under a lobby-specific salt, and
reject unsigned, tampered or foreign-signed ids with a 400. The raw
UUID is still used internally for the cache and LiveKit identity.
The lobby system relied on cookies to identify the participant
across the wait/enter cycle, which does not work in an iframe
context where our cookies are dropped.
Simplify the lobby behavior:
* The POST request that enters the lobby now returns the
participant id in the response.
* The frontend passes that id back on subsequent requests to keep a
sticky session while trying to enter the room.
This moves a bit more logic to the frontend but should be a
transparent refactoring, without decreasing the security of the
lobby flow.
Some integrators render our videoconference inside an iframe, where
our cookie-based authentication does not work: our cookies are
SameSite=Lax/Strict, so the iframe drops them.
We looked at what Jitsi offers: a shared secret used to sign JWTs
that authenticate users coming from external services. Since we
already expose an external API where third parties authenticate as
a given user, it was simpler for us to add an exchange mechanism on
top of that.
Flow:
* Through the external API, mint a short-lived, single-use exchange
code for a user.
* The third party hands that code to the frontend as a URL fragment.
* The frontend exchanges the code for a longer-lived JWT that can be
used to query the regular API viewsets.
Known limitations and follow-ups:
* At some point it would be nice to shorten the JWT lifetime and
add a refresh mechanism. This will be handled in a follow-up PR
when actually needed.
* CSP rules to control which origins are allowed to embed the app
in an iframe still need to be added.
* This alternative authentication cannot easily be scoped to a
subset of endpoints without adding a lot of complexity, so it is
accepted globally on the API for now.
Add new options to query start-start recording API. A resolution
("540p", "720p", "1080p") and a profile ("talking_heads", "text", "mixed")
are resolved to provide a width, height, fps and bitrate which
are passed on to the encoder. Using profiles allows for some flexibility
on quality if necessary without changing front facing user config.
Co-authored-by: sarthakbahal <sarthakbahal.45@gmail.com>
The per-minute room creation throttle absorbs bursts but does not stop
a compromised account from steadily creating rooms over hours or days.
Add RoomCreationDailyUserRateThrottle, a per-user throttle with its own
"room_creation_daily" scope, applied to room creation only alongside
the existing short-term throttle. It defaults to 1000 rooms per day and
is configurable via ROOM_CREATION_DAILY_THROTTLE_RATES.
Tests use a controllable clock and patch rates with monkeypatch so they
are restored after each test.
Add throttling on the endpoint used to generate meeting links, so a
compromised authenticated account cannot silently generate thousands
of links without hitting any suspicious errors or alerts.
The limits are set high enough not to affect legitimate usage, while
capping the damage a leaked account can do.
AUTHENTICATED_PARTICIPANTS_CAN_EDIT_DISPLAY_NAME was only enforced at
LiveKit token generation and by hiding the name field in the frontend.
The `rooms/{id}/rename/` endpoint never checked it, so any authenticated
user with a valid room token could rename themselves via the API even
when the self-hoster had disabled it.
Return 403 from the rename action for authenticated users when the
setting is disabled, mirroring the `can_edit` rule in
`core.utils.generate_token`. Anonymous participants are unaffected, as
they have no account name to fall back on.
Add tests covering the disabled/enabled cases for authenticated users
and the anonymous exception.
Adds support for serving media behind Traefik, which currently cannot work
at all.
The media-auth subrequest views read the original request URL from a
hardcoded HTTP_X_ORIGINAL_URL header. That header is an nginx-ingress
convention. Traefik's ForwardAuth middleware sends X-Forwarded-Uri instead
and has no mechanism to emit X-Original-URL, so behind Traefik every
recording download and file attachment is rejected with a bare 403 --
indistinguishable from a legitimate permission denial, which makes it
painful to diagnose.
Add MEDIA_AUTH_ORIGINAL_URL_HEADER, defaulting to HTTP_X_ORIGINAL_URL so
existing nginx-ingress deployments are unaffected. Traefik deployments set
it to HTTP_X_FORWARDED_URI. It is used in both places that resolve the
header: RecordingViewSet._auth_get_original_url and the file attachment
_authorize_subrequest. The log message on a missing header now names the
header actually expected, which is what makes the failure diagnosable.
This mirrors the setting the sibling Docs project already exposes
(suitenumerique/docs, MEDIA_AUTH_ORIGINAL_URL_HEADER) for the same reason.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Recordings used to be finalized by an inbound notifications sent by
S3. This tied the recording lifecycle to bucket notifications, adding
complexity and dependency to limited S3 services.
The LiveKit egress_ended webhook, added as a fallback in aee1847, does
the same job without any object-storage dependency. Make it the only
mechanism: RecordingEventsService.handle_complete is now called on
EGRESS_COMPLETE / EGRESS_LIMIT_REACHED unconditionally, instead of only
when RECORDING_STORAGE_EVENT_ENABLE is False. Remove the storage-event
path entirely.
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.
Refactor CONNECTION_TEST_ROOM_MAX_AGE_SECONDS so it is no longer an
independent setting but a quantity derived from (or added on top of)
the token TTL.
This prevents a misconfiguration where the token would outlive the
delete-room callback. In that case, an attacker holding a valid
token could recreate the room after the callback fired and escape
the intended cleanup.
Currently users have no way to reliably test their connection before
joining a room. To address this, we plan to build a connection-test
page.
The testing requires a dedicated LiveKit token, issued without going
through the room API, which is tied to registered meetings, lobby
rules, and longer-lived access tokens.
Introduce a new viewset for all diagnostics-related features. The
first route issues a token for diagnostics, even for anonymous
users. Each request creates a new dedicated room so users never
share the same LiveKit room during tests. Tokens are short-lived
(default 10 minutes) to limit reuse, and the endpoint is throttled
to prevent abuse.
A Celery worker also schedules a callback that deletes the room
after a certain delay, in every case.
Update the API so that, when a user creates a new meeting without
passing an explicit configuration, the user's persisted preferences
are applied as defaults.
This allows a user to, for example, enable the waiting room by
default on every meeting they create.
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.
The info panel was crashing when opening a room that was not
registered in the database (with ALLOW_UNREGISTERED_ROOMS=true),
because the API response did not include the room slug.
Instead of adding frontend fallbacks, update the unregistered-room
response to include the slug, keeping the API contract consistent
with registered rooms.
Note: this still relies on the unregistered-room response staying
aligned with the registered-room schema. Any future divergence
between the two responses could introduce similar issues.
A refactoring on the backend side is needed.
It closes#1441.
This commit introduces the compatibility with summary v2.
It tecnically doesn't break the compatibility with v1 as
v1 params are still sent. But we advise people using the
transcribe feature in their own deployments to adapt to the
new v2 API, as this compatibility will be removed in a
future major version.
* RecordingStatusChoices now has
EXTERNAL_PROCESS_SUCCESSFUL
& EXTERNAL_PROCESS_FAILED
Values, which are changed by a new webhook that
can be called by the transcribe service.
This webhook is protected by its own bearer token.
* Title for the document is computed in visio,
* Tests are added / updated accordingly
Recording lifecycle previously relied exclusively on the MinIO storage-hook
endpoint to transition from STOPPED to SAVED, which made the system dependent
on MinIO bucket notifications and lifecycle configuration. Introduce support
for LiveKit egress_ended webhook (EGRESS_COMPLETE, EGRESS_LIMIT_REACHED) as
an alternative finalization mechanism for self-hosted deployments that do
not use MinIO / S3 hooks.
Change behavior of existing configuation RECORDING_STORAGE_EVENT_ENABLE.
When the LiveKit mechanism is enabled (RECORDING_STORAGE_EVENT_ENABLE=False),
RecordingEventsService.handle_complete is triggered from
LiveKitEventsService._handle_egress_ended.
Since we have added custom backgrounds, they could be
soft deleted but were never really deleted.
This commits introduces a command to actually delete
this files.
In introduces also a command to purge pending upload
.
With the addition of the ANALYSING state
files could be accessed in the short time they
were in that state.
We now require files to be in ready.
Also adds missing frontend types (no impact).
When analysing a file, the previous commit introduced a row level lock
to make sure we would analyse and promote a single file.
This commit changes the locking mechanism so that it happens with
the upload state which avoids long running db locks and potential
perf issues.
Before this commit, post a file check, the policy could be
reused to change the verified file.
Now, files are uplaoded to a temporary location, then inside
a transaction that prevents concurrent calls, the file is
copied to its final destination and the checks are run on that one.
A new file can still be updated with the policy but it will never be read, etc.
As part of this change, all files in the new tmp directory
on s3 should have an expiration policy.
Ensure the participant requesting a mute action is still present
in the room before processing the request.
This mitigates scenarios where a previously issued token could be
reused after the meeting has ended.
Current token lifetime is intentionally long-lived and will be
refactored in the future to better align with LiveKit session
constraints. In the meantime, add this extra validation step to
reduce the attack surface.
Extend the existing live synchronization mechanism beyond room
configuration to also include lobby access level changes.
This ensures that all owners and admins sharing a room maintain a
consistent and up-to-date view of room state in the frontend,
including configuration and access control updates.
Introduce synchronization of room configuration changes across
active participants.
When a room configuration is updated through a PUT operation, the
backend now performs an additional LiveKit API call to notify room
participants through a room metadata update event.
This ensures admins and owners quickly see up-to-date settings in
their administration panel. It also prepares the frontend for
automatic updates of unprivileged participants room’s data without
refetching it from the API.
An event-driven design was chosen instead of storing the full room
configuration in LiveKit metadata. While embedding the state
directly in metadata would provide immediate synchronization, it
would also require initializing and maintaining configuration
state during room creation or webhook handling, increasing the
risk of operational failures and regressions.
Instead, the backend emits lightweight synchronization events and
active clients update their React Query cache, which remains the
single source of truth for room configuration data.
Enable any participant to mute others when the room configuration
allows it. This is enabled by default for all meetings unless
explicitly disabled by an administrator.
Privileged users retain the ability to mute any participant
regardless of the room configuration.
Introduce a new user assignment mechanism to for more friendly output
than the current (SPEAKER_0, SPEAKER_1, ...). Use the VAD metadata to
compare speech intervals with those returned by WhisperX. User with the
highest overlap score above a defined threshold is assigned to each segment.
This method allows for multi-speaker scenarios for a single account.
Wrap Recording and RecordingAccess creation in a single transaction so a
partial failure does not leave orphan rows, and return 409 instead of 500
when a recording is already in progress for the room.
When the worker fails to start, transition the Recording to
FAILED_TO_START so the unique partial constraint on (room, status) no
longer blocks future recording attempts on the same room.
Allow controlling when the metadata collector agent is started,
enabling users to try the feature and disable it if needed.
Introduce a user-level feature flag to toggle the agent for the
initial release.
Introduce MetadataCollector and MetadataCollectorService classes to
centralize the collection and storage of user connections, VAD events,
and chat messages. This creates a structured foundation for future speaker
assignment logic based on voice activity detection. Add tests for this new
feature.
Avoid mapping all Twirp errors to generic 500 responses.
Explicitly handle the case where a participant is no longer in
the room, as this may indicate suspicious behavior or a client
state issue.
Improve error discrimination to provide more accurate responses.
Introduce toggle-hand and rename endpoints in RoomViewSet,
secured with LiveKit token authentication.
Remove direct permission for clients to update their own metadata
via LiveKit tokens to prevent spoofing (e.g. faking admin status).
Proxy participant metadata updates through the backend to enforce
proper validation and authorization.
Signed-off-by: lebaudantoine <lebaud.antoine131@gmail.com>
Sanitize error handling to prevent leaking internal details when
invalid or malicious requests are sent to the API.
Return generic error responses to reduce the risk of information
disclosure during probing attempts.
Update the response message to explicitly state that certain
notifications are ignored on purpose, avoiding confusion
during debugging or log inspection.
With the introduction of background file uploads, a misconfigured
MinIO webhook could trigger the storage hook endpoint for unrelated
files.
While the dev setup now filters events via the MinIO lifecycle
configuration, add a safeguard at the application level.
Enforce a stricter filepath regex when parsing storage hook events
and ignore files outside the recording output directory.
Return a clean 200 response to acknowledge the webhook while
avoiding unnecessary processing.
Combine the regex used in Drive with the one from the recording
feature and centralize them in the enums module.
Although the module name suggests only enums, it also hosts
shared constants used across the codebase.
Add FILE_UPLOAD_ENABLED setting (default to False, to avoid
a breaking change). Also adds a max_count_by_user sub setting
to restrict the number of uploaded files per user.
Remove the user-provided filename while preserving the extension,
and switch to the format `uuid.extension`.
This is more natural than the previous `uuid/.extension` format
and avoids confusion.
Update related tests accordingly.
Throttle the request-entry endpoint for authenticated users also
to guard against accidental hammering from buggy clients.
Authenticated users are throttled via RequestEntryUserRateThrottle.
Anonymous users are throttled using the lobby participant cookie
through RequestEntryAnonRateThrottle.
Claude