* fix(api): throttle api_keys last_used_at writes in auth middleware
Every API key request spawned a goroutine that ran an UPDATE on
api_keys, so a key driving HLS segments or a polling integration hit the
table with one write per request, and a stalled database could pile
those goroutines up without bound. The jellycompat authenticator already
guards this same write with a once-per-minute throttle per key; the main
middleware was missing it.
Bring the two in line. Track the last write per key ID and only launch
the update once a minute has passed, with a timeout on the background
write. The map is keyed by key ID so it stays bounded.
* fix(auth): bound API key last-used throttling
---------
Co-authored-by: Quick104 <31828688+Quick104@users.noreply.github.com>
* fix(web): show admin chrome only on the admin account's primary profile
The top-right ServerActivity indicator and the sidebar Admin section were
gated on the account-level role alone, so every profile on an admin
account — including child profiles — saw admin system notifications and
the indicator polled four admin endpoints on their behalf. Gate both on
the active profile being the household primary, matching the existing
is_primary idiom in SettingsLayout and the server-side quota exemption.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(web): resolve active profile via useCurrentProfile in admin route gates
RequireAdmin/RequirePrimaryOrAdmin read the profile from useAuth(), but the
admin chrome (AppSidebar, Layout) gates on useCurrentProfile(), which resolves
the selected profile. Use the same source in the route gates so the redirect
and the visible admin UI can never disagree.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(web,api): centralize acting-admin policy and enforce it server-side
Address code-review findings on the primary-profile admin gate:
- Add isActingAdmin to web/src/lib/permissions.ts as the single
client-side definition of the policy (admin role + primary or no
profile), with a useIsActingAdmin hook on top. Route gates, sidebar,
Layout, and realtime channel gating all use it now, so the gate and
the chrome can no longer disagree on null-profile handling.
- Convert the admin-gated surfaces the original change missed
(MediaItemMenu, EditMetadataDialog images tab, AddToCollectionDialog,
MarkerEditor, theme CatalogBrowser, PersonDetail, SettingsLayout,
ItemDetail content pages) so an admin on a non-primary profile is a
regular viewer everywhere, not just in the sidebar.
- Make the role-derived permission bypass (metadata curation, marker
edit) follow the same policy on both client and server.
- Enforce the policy server-side: RequireActingAdmin middleware refuses
admin routes when the request declares a non-primary profile via
X-Profile-Id, and the metadata-curation middleware holds admins on
non-primary profiles to explicitly assigned permissions.
- Stop spreading the profiles query result from useCurrentProfile so
route gates only re-render when the resolved profile changes, and
make it safe outside AuthProvider.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(web,api): fail closed on unresolved profiles in acting-admin policy
Address review feedback on the acting-admin gate:
- Server: actingAdminAllowed now denies when the declared profile cannot
be resolved to one of the caller's profiles, so a bogus X-Profile-Id
can no longer restore admin powers to a non-primary session.
- Client: useIsActingAdmin returns false while a selected profile id has
not yet resolved (e.g. hard refresh before the profiles query
returns), instead of briefly treating it as "no profile selected".
useCurrentProfile exposes hasSelectedProfile to make that state
distinguishable.
- hasPermission/canCurateMetadata/canEditMarkers now require the profile
argument (resolved profile or explicit null), so a missed call site
fails the typecheck instead of silently restoring the admin bypass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Code <noreply@anthropic.com>
Co-authored-by: Quick <31828688+Quick104@users.noreply.github.com>
Cap how many Whisper transcription jobs each user account can start per
rolling window (day/week/month), configurable from admin settings. The
player modal shows remaining usage and the server returns 429 with
details when the limit is hit.
Enforcement is atomic with the job insert (per-user advisory lock, same
pattern as media-request quotas), so concurrent requests cannot race
past the limit. Failed/cancelled jobs that never produced transcription
work are refunded. Exemption applies to the admin account's primary
profile only; other profiles on an admin account stay subject to the
quota. A partial index covers the quota count, a malformed quota
setting row degrades to "no quota" instead of blocking startup, and the
period vocabulary and admin-role predicate are each defined once
(ai.ValidQuotaPeriod, apimw.IsAdmin).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
