Open shinypb opened 2 years ago
@shinypb Thanks for the feature request! We're currently working on Multi-Tenant Realtime and will consider adding your feature request to the roadmap.
Thanks for the quick response, @w3b6x9. It occurred to me earlier this morning that a simple “include data values in Realtime events” checkbox would cover my use case. Being able to receive notifications of which fields changed without actually including the changed values seems like it might be simpler to implement and reason about than having per-field visibility.
Quick update on this, yeah this is something we could do with column level security baked into Postgres. We're close to releasing the latest version of Realtime. Once we've merged that into this repo we will revisit these enhancements.
Feature request
I would like to receive realtime updates for a table without exposing all of the fields within a given row. Allow me to explain a simplified version of what I am trying to build.
I have API endpoints for creating, reading, and writing to
KeyValue
objects, which are just key-value stores. Users should be able to share either write or read-only access to these objects with other users. My schema looks something like this:Access to a particular
KeyValue
instance gated by the use of either thereadKey
or thewriteKey
; a user can create anKeyValue
object and give another user read-only access by sharing itsid
and thereadKey
with them.Having realtime updates for this system is desirable, but Supabase's current implementation means that the
writeKey
would be visible to anyone with thereadKey
, which defeats the point.Describe the solution you'd like
Within the Supabase UI, I'd like to be able to block particular fields from ever being included in realtime updates.
Describe alternatives you've considered
I could work around the lack of field visibility controls by breaking my object up into two tables; something like...
In this universe, I can subscribe to realtime updates on the
KeyValueData
table without leaking sensitive data. However, this is a bit of a contortion to satisfying the system, and I'd prefer to keep things in a single table if possible.