favorites
user_id
Supabase Auth user id. Each row belongs to one authenticated account.
Module 9.2
Supabase favorites table and RLS
This Demo Lab page documents the cloud storage boundary for future favorites. EventMap does not read or write cloud favorites yet.
SQL migration
Run the SQL file in Supabase Studio
Copy the project SQL file into Supabase Studio SQL Editor and run it against the course project database.
supabase/sql/001_favorites_rls.sqlfavorites
event_id
EventMap event id. Together with user_id it forms the primary key.
favorites
event_snapshot
A JSON snapshot of EventCardData for future cloud favorites UI.
favorites
created_at / updated_at
Server timestamps for storage metadata.
RLS policy
SELECT
Authenticated users can read only rows where auth.uid() equals user_id.
RLS policy
INSERT
with check prevents a browser request from creating a row for another user.
RLS policy
DELETE
A user can remove only their own favorite rows.
RLS checklist
What must be true before browser access is safe
favorites table shape
public.favorites stores user_id, event_id and event_snapshot for each saved event.
RLS enabled
Row Level Security is enabled before browser-facing access is allowed.
authenticated grants
The authenticated role receives select, insert and delete grants for public.favorites.
SELECT own rows
The SELECT policy compares auth.uid() with user_id.
INSERT own rows
The INSERT policy uses with check so a user can only create rows for their own user_id.
DELETE own rows
The DELETE policy compares auth.uid() with user_id before removing a favorite.
publishable key paired with RLS
The browser client uses a publishable key, while row access stays protected by grants and policies.
Publishable key + RLS
The key can be public, the rows cannot
A publishable key is expected in the browser client. It is safe only when the table grants are narrow and RLS policies scope every row to the current auth.uid(). Secret or service-role keys never belong in a Next.js frontend.