Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Hey HN, Supabase is an open source Firebase alternative. We're building the features of Firebase using enterprise-grade open source tools. We're particularly focused on scalability. We take proven tools like Postgres, and we make them as easy to use as Firebase.
Today, Supabase is adding Row Level Security (RLS) to our Realtime engine.
The linked blog post goes into depth around the technical implementation, so I’ll just give a recap for the people who jump straight to comments (like me).
Supabase was launched here on HN when we open sourced our Realtime engine[0] - an Elixir server which clients (i.e. website visitors/users) can connect to via websockets and receive a stream of PostgreSQL changes.
The server receives those changes via a logical replication slot - the same system that PostgreSQL uses for replicating to other databases.
To achieve RLS we added a few SQL functions, the main one is apply_rls[1] which the stream is filtered through. For every user connected to the Elixir server, the Postgres function checks if they have access to the database change and appends an array of allowed user IDs. The Realtime server then delivers the change to the user only if the connected user is matched in this array.
This one has been a long time coming, and it's one of the reasons why we have maintained our "beta" badge for so long. A few of the team will be here to answer any questions - my cofounder @awalias and @steve-chavez from PostgREST, @inian, @wenbo and @1_over_n
[0] [Realtime Show HN](https://news.ycombinator.com/item?id=22114560)
[1] [SQL function](https://github.com/supabase/realtime/blob/master/server/priv...)
In Supabase we use a separate Auth server [0]. This stores the user in an `auth` schema, and these users can login to receive a JWT. Inside the JWT is a "role", which is, in fact, a PostgreSQL role ("authenticated") that has certain grants associated to it, and the user ID (a UUID).
Inside your RLS Policies you can use anything stored inside the JWT. My cofounder made a video [1] on this which is quite concise. Our way of handling this is just an extension of the PostgREST Auth recommendations: https://postgrest.org/en/v9.0/auth.html
[0] Auth server: https://github.com/supabase/gotrue
[1] RLS Video: https://supabase.com/docs/learn/auth-deep-dive/auth-row-leve...
Of course this is PostgREST-specific, only when going through it you'd enforce this condition.
[1]: https://github.com/PostgREST/postgrest/issues/2028