Realtime Broadcast and Presence Authorization #22484
Replies: 4 comments 22 replies
-
hey @filipecabaco, great work + write up! I know this is for a future iteration, but please integrate postgres changes with this concept, so that a user can define a "publisher" for a channel. right now, realtime + rls is hammering our database resources and this would finally solve it. |
Beta Was this translation helpful? Give feedback.
-
Sort of fuzzy (quick read) is this RLS only applied on the channel connection (and maybe token refresh) or is the database call made for every message and RLS has to run on the table(tables for joins) for each message. The latter would open up alot of need for performance testing with RLS policies. |
Beta Was this translation helpful? Give feedback.
-
@GaryAustin1 @psteinroe @silentworks updated the discussion. We need to understand what is the kind of developer experience that will be best to support users use cases so we now have 3 options to discuss and reach an agreement in the community on what could be the best approach. |
Beta Was this translation helpful? Give feedback.
-
Hello @filipecabaco is this yet implemented or is there potential steps I am missing out on? Since the RLS is not triggered whatsoever after following your thread. I am also altering the realtime's broadcast table to enable row level security in my schema SQL migration file. |
Beta Was this translation helpful? Give feedback.
-
Github Discussion for Realtime Authz
Overview
This post explains how authorization works for Realtime Broadcast and Realtime Presence.
This allows you (the developer) to control access to Realtime Channels. We use Postgres Row Level Security to manage access. Developers create “Policies” which allow or deny access for your users.
How it works
💡 This will only happen when your client connects. After that we will retain the permissions during the duration of the JWT session1.Fetch the Channel
Based on the config received we extract the channel name and fetch it from the database to be used further in our checks
2. Set Connection Context
We start a transaction against you project database where we initial set some information we extracted from the JWT, the channel we fetched previously and the Headers from the connection request.
3. Run RLS checks
Using support tables set in the
realtime
schema we will run queries to check if the user within the current transaction is able to connect the channel, read/broadcast in that given channel (Broadcast feature) or track/sync in the given channel (Presence feature) the information they want to.Request for Feedback
Due to the complexity of this system we want to receive feedback on the developer experience you would like to see and use so we can guide our development towards the right direction.
Assume that this will be the way we will protect all current and future features from Realtime.
Option 1 - Channel table with feature tables
Example
Requires the following support tables for this use case to properly map users against rooms
Option 2 - Single Table for Channel
Example
Requires the following support tables for this use case to properly map users against rooms
Option 3 - Channel / Messages tables
Example
Beta Was this translation helpful? Give feedback.
All reactions