aarbit
4b757e89f5
RLS is the real guard (diagram_collaborators_insert/update now reject user_id = the diagram's owner, regardless of who's performing the write — covers a Super Admin acting on someone else's diagram too, not just the normal owner path); the client-side check in SupabaseDiagramCollaboratorRepository.add is just there to surface a friendly message instead of the raw 42501. Verified: tsc -b and oxlint clean; supabase db reset + 53/53 pgTAP tests pass (1 new test).
30 lines
1.4 KiB
SQL
30 lines
1.4 KiB
SQL
-- Prevents a diagram's owner from ending up as their own collaborator row
|
|
-- (found via manual testing: the UI let you "share" a diagram with
|
|
-- yourself). Ownership already implies full access, so a self-collaborator
|
|
-- row is never meaningful — enforced here, not just in the client, since
|
|
-- the client-side check alone wouldn't stop a Super Admin's "add on behalf
|
|
-- of the owner" path or any other direct API access from creating one.
|
|
|
|
drop policy "diagram_collaborators_insert" on public.diagram_collaborators;
|
|
|
|
create policy "diagram_collaborators_insert" on public.diagram_collaborators for insert
|
|
with check (
|
|
(public.is_super_admin() or public.diagram_owner_id(diagram_id) = auth.uid())
|
|
and user_id != public.diagram_owner_id(diagram_id)
|
|
);
|
|
|
|
-- The existing update policy had no WITH CHECK at all (only USING) — added
|
|
-- here too, defensively, in case user_id (part of the primary key) is ever
|
|
-- changed via UPDATE rather than delete+insert.
|
|
drop policy "diagram_collaborators_update" on public.diagram_collaborators;
|
|
|
|
create policy "diagram_collaborators_update" on public.diagram_collaborators for update
|
|
using (
|
|
public.is_super_admin()
|
|
or public.diagram_owner_id(diagram_id) = auth.uid()
|
|
)
|
|
with check (
|
|
(public.is_super_admin() or public.diagram_owner_id(diagram_id) = auth.uid())
|
|
and user_id != public.diagram_owner_id(diagram_id)
|
|
);
|