Need help understanding something RLS related
Hello, I need help with something RLS related. This is my problem. Let's say I have a Next.js app with Supabase auth and one table called "Profiles". Profiles table has a row "id" that is both primary key and foreign key in auth schema "users.id". Table also has rows like first name, last name, created at and updated at. I want everyone to be able to list out the all the users first names and last names. I also want user to be able to update his own first name and last name. I also want no one to be able to do anything with id, created at and updated at. Now the standard workflow i thought about was creating the table, enabling RLS, creating RLS policy to allow anyone to select rows in Profiles and another RLS policy that allows only the user to update his rows. Now the problem is that anyone can check each others private columns like id, created at and updated at. I can use revoke access from "public" for those columns. So every time i make a table that has private columns i make a revoke access from public for those columns.
I have a few questions:
1. Is this workflow correct and industry standard?
2. How can I stop a user from grabbing the Supabase public key and running his custom queries and burning down my Database CPU since RLS will be checked for every row?
The last question is the reason why I'm just thinking about locking down all the tables with RLS, making no RLS policies and just using an ORM that connects to the Supabase postgres directly with bypass RLS meaning that users can only interact with the server side services i create in my app and that if they tried using any custom queries to burn down the CPU they would just hit a RLS wall that is O(1) complexity.
I'm interested if anyone has experienced the same problem and dilemma and what was their result for production (cost difference, security problems, etc.)
Any help is welcome
I have a few questions:
1. Is this workflow correct and industry standard?
2. How can I stop a user from grabbing the Supabase public key and running his custom queries and burning down my Database CPU since RLS will be checked for every row?
The last question is the reason why I'm just thinking about locking down all the tables with RLS, making no RLS policies and just using an ORM that connects to the Supabase postgres directly with bypass RLS meaning that users can only interact with the server side services i create in my app and that if they tried using any custom queries to burn down the CPU they would just hit a RLS wall that is O(1) complexity.
I'm interested if anyone has experienced the same problem and dilemma and what was their result for production (cost difference, security problems, etc.)
Any help is welcome
