Proper RLS for audit table
In our project, we have a table where we keep an audit of any other changes made to the other tables, the data is populated via triggers on the other tables, for example, if someone updates a field on table1, a Supabase trigger will store the old value, new value, column name, table name and the id of who made the change.
I'm struggling to figure it out what would be the proper RLS for that audit table. It will not be queried on the application, it is only for record keeping and the only way it gets data populated is from the Supabase triggers on the other tables.
Can anyone share some ideas?
1 Reply
Block everything with no RLS policies.
Use a security definer function with your trigger to do the inserts.
Just be careful of what you log...
Supabase does not log data in the requests to the API because they don't know if it is confidential or would have to be deleted if the user leaves.