RLS is the best invention since sliced bread. From your datamodel I conclude that you are not using postgresql roles (login and group). Is there a reason to create these extra tables? Is there a reason to not rely on the postgresql authentication of end-users?
The Supabase platform doesn't seem to use postgresql authentication? I'm not entirely sure. They do provide two postgres roles, "anon" and "authenticated". And an "auth.uid()" helper function. A user is assigned one of those roles based on whether they've signed into the Supabase auth system. I've used the "authenticated" role where it makes sense and "auth.uid()" extensively, but otherwise postgres doesn't know a user's identity. At least on Supabase.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
RLS is the best invention since sliced bread. From your datamodel I conclude that you are not using postgresql roles (login and group). Is there a reason to create these extra tables? Is there a reason to not rely on the postgresql authentication of end-users?
The Supabase platform doesn't seem to use postgresql authentication? I'm not entirely sure. They do provide two postgres roles, "anon" and "authenticated". And an "auth.uid()" helper function. A user is assigned one of those roles based on whether they've signed into the Supabase auth system. I've used the "authenticated" role where it makes sense and "auth.uid()" extensively, but otherwise postgres doesn't know a user's identity. At least on Supabase.