feat(dashboard): Add column-level privileges management

[HTMHell]

New Feature: Column-level Privileges Management in Supabase Dashboard

This Pull Request introduces a new feature for managing column-level privileges in the Supabase Dashboard. With this enhancement, users can now seamlessly view and modify table privileges for each role.

Key Benefits

Column-level security comes in handy when you want to grant specific actions to certain roles, but restrict access to specific columns. For instance, this is particularly useful when you allow authenticated users to insert or update records but want to prevent them from modifying the values of certain critical columns (e.g. created_at or updated_at).

Features include

• Effortlessly view and edit column-level privileges in the dashboard
• Improve security and control by specifying permissions per column for each role
• Enhance overall flexibility and customization in managing database access and operations

Here is a quick demo:

Screenshare.-.2023-04-15.2_45_09.PM.mp4

[vercel]

@HTMHell is attempting to deploy a commit to the Supabase Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
studio-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 10, 2024 6:28am
supabase-studio-prod	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 10, 2024 6:28am
supabase-studio-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 10, 2024 6:28am

6 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
database-new	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am
docs	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am
studio	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am
studio-self-hosted	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am
ui-storybook	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am
zone-www-dot-com	⬜️ Ignored (Inspect)	Visit Preview		Jan 10, 2024 6:28am

[alaister]

Hey @HTMHell,

First off, what an awesome PR! Thanks for the hard work here 💪🏻

We've been planning this feature for a while now, along with refactoring our RLS interface (possibly consolidating the two). The frontend team will need to discuss how to best get your changes in, as they'll be a fair amount of overlap.

We'll keep you updated, and thanks again! 🙌🏻

[HTMHell]

Hey @HTMHell,

First off, what an awesome PR! Thanks for the hard work here 💪🏻

We've been planning this feature for a while now, along with refactoring our RLS interface (possibly consolidating the two). The frontend team will need to discuss how to best get your changes in, as they'll be a fair amount of overlap.

We'll keep you updated, and thanks again! 🙌🏻

cool, thank you!

[squallsama]

This functionality could be really useful. Hope that Supa ase team will merge this pull request.

[eqoram]

This is awesome! Highly appreciate it @HTMHell

[saltcod]

Hey @HTMHell !

1. Amazing github handle!
2. Also amazing first PR! Thank you so much for it!

While we continue to debate the UI for this, wondering if you could have a peek at the data handling. It looks like you're loading it’s currently loading all the permissions for all tables on load. Could you limit that to just the table in the current view. Some of these tables could be loading MBs of data.

with thanks!

[HTMHell]

Thank you!
Yes, that makes sense. At first, I loaded the data for all tables because I listed all the tables on the screen. However, it introduced UI performance issues because of the many toggles, so I limited it to one table.

I will probably have time for this in a few days.

[HTMHell]

@saltcod I've made the changes, it will load the data for the selected table only

[saltcod]

Hey @HTMHell let's try and get this in this week! Just had a look and things are looking great.

Noticed this in light mode:

Wondering if we also need any kind of docs for this?

[HTMHell]

@saltcod Good call, I've never noticed there is a light theme! Can you elaborate on the docs, what were you thinking about?

[saltcod]

Sorry @HTMHell — for docs, I meant should we write something to indicate how users should use this feature, and how it would interact with RLS

What does it impact, and how. How should people use this. Those sorts of questions.

[akarshghale]

Looks like you guys are ready to merge this branch soon. Any updates on it?

[cco3]

Thanks! This looks really cool!

[alaister]

Hey everyone,

We've released this as a feature preview. You can toggle it on for your projects here:

Please send us any feedback on this discussion: https://github.com/orgs/supabase/discussions/20295

[akarshghale]

Hey @alaister,

Thanks for the feature! I have a few questions regarding this:

1. I can see the SELECT '*' will break the queries. But what if the privileges have only been revoked for UPDATE & INSERT? From my testing I don't think it applies there. Can you confirm?

2. Can you please elaborate on this? If you remove a column privilege for a role, that role will lose all access to that column. If i remove INSERT privilege only I can still UPDATE the column so I don't understand the message here.

Thanks!

[alaister]

Hi @akarshghale,

1. As long as you're not trying to insert or update those revoked columns both operations should be fine.
2. You're right the wording could be clearer here. It should be lose all access to that column for that operation.

Hope this helps!

[bitnom]

This has made my life

[rohankm]

is there any way to SELECT '*' to return only the columns the role has access to it?

[rohankm]

other roles or custom roles are not being shown in the select option

[jdgamble555]

The link at the bottom in the preview toggle popup does not go to the right place fwi:

It goes here:
https://supabase.com/project/YOUR_PROJECT_ID/auth/column-privileges

Instead of here:
https://supabase.com/dashboard/project/YOUR_PROJECT_ID/auth/column-privileges

J

[xleddyl]

It would be cool if the SELECT(*) automatically returned only the columns for which one has authorization

[bombillazo]

That would require some sort of dynamic query, I don't think there is such a construct at the SQL level to "auto-hide" columns with no privileges (that I know of). While there's no luck in the DB domain, the JS client could abstract that, but it would need to know the privileges beforehand to construct the dynamic query fields...

[xleddyl]

That would require some sort of dynamic query, I don't think there is such a construct at the SQL level to "auto-hide" columns with no privileges (that I know of). While there's no luck in the DB domain, the JS client could abstract that, but it would need to know the privileges beforehand to construct the dynamic query fields...

Yes, perhaps a mechanism similar to the one for generating types from the database schema, which is able to understand which columns are visible to a specific role. Definitely needs to be handled at the library level.

[jdgamble555]

This might could be a good postgREST feature request.

J