We saw in the previous lesson that making buckets private is one of the easier ways to restrict access to assets within the bucket. But this black-and-white access control may not be enough in all use cases. Blissfully, since Supabase Storage uses Postgres internally for storage metadata, we have access to mighty RLS, and thus we can write complex access policies on storage access.
But before we start writing RLS policies, we need to understand how the metadata is stored in the Postgres DB.
If we go to the storage schema in our DB, we can see three tables. These tables are read only as it is managed by supabase, and changing anything in these tables may cause things to break. The two tables relevant to this lesson are:
buckets table: This table contains information about each bucket. We can see entries for the buckets we created in the previous lesson. This contains details such as whether the bucket is public or not, file size limit, allowed media type, and other metadata.objects table: This table contains info for each object or asset in the storage. Here, we can see the images we added to our storage. This contains info like the name, parent bucket, path and other metadata of the asset.To manage access on bucket level operations (such as creating a new bucket, or updating/deleting an existing bucket), we need to add RLS policies on the buckets table.
