Realtime Broadcast and Presence Authorization #22484
Replies: 12 comments 37 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.
-
Discussion has been updated with solution chosen, if you want to test it out please do contact support with a request to enable it for your project. |
Beta Was this translation helpful? Give feedback.
-
quick question: from a dx perspective, why do I need to set auth on the realtime client explicitly? Is this just because its not released and properly integrated into supabase-js yet? client.realtime.setAuth(
(await client.auth.getSession()).data.session.access_token
); |
Beta Was this translation helpful? Give feedback.
-
hey @filipecabaco, I am looking into this now and one thing in this design that I am not friendly with yet is that the authorisation is very coupled with the event type. Example:
Am I missing something, or is this how its supposed to be designed with the new realtime auth? |
Beta Was this translation helpful? Give feedback.
-
I was testing the new JS code and I'm sure this is known but probably will want to document it. This makes sense, but is sort of a security thing to think about if you change RLS. |
Beta Was this translation helpful? Give feedback.
-
FYI we've moved the feature to Public Beta |
Beta Was this translation helpful? Give feedback.
-
While trying to debug authorized real time calls, I noticed that sending Related bug that this would have helped with for debugging: |
Beta Was this translation helpful? Give feedback.
-
Need an option to disable public channels or this product is DOA for scalable production use. Anyone can be spammed infinitely and incur skyrocketed usage costs just by setting private to false. I don't even use Realtime atm and the fact that this is exposed to the public is scary as heck. I could write a bot in 2 minutes that will max out all of anyone's quota just with an Anon key. This is also putting everyone who uses Supabase at risk just by existing, and should be immediately disabled for all accounts or set a quota cap and not allow overages. |
Beta Was this translation helpful? Give feedback.
-
I see there is a message cap of 500 messages per second for pro accounts. That means that any bot can send 500 messages per second. There's 2,628,288 seconds in 30 days. So that's 1,314,144,000 messages that can be sent. 1.3 billion messages can be spammed per month to any Supabase project with just an Anon key and minimal coding knowledge. Pricing for Pro plan -> 1309144000 messages in overages per month. Divided by 1 million and multiplied by $2.50 you get $3,272.86 in cost that could be easily imposed on any Pro tier Supabase project just by this existing. This is a huge security hole. |
Beta Was this translation helpful? Give feedback.
-
Update
Discussion has been updated with solution chosen.
Realtime Authorization for Broadcast and Presence is now available in Public Beta.
See the official documentation.
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.
Usage
Creating Realtime Policies
Using Studio’s SQL editor you can set RLS rules against the table
realtime.messages
which will define the rules for your users.Since you are using RLS policies you can do more complex examples.
In a scenario where you have a schema with a table for rooms and one that creates an association between rooms and users.
We'll use this example schema to be showcase RLS policies limiting Realtime functionality
We can build more complex RLS rules using this information:
Testing Authorization
Now to test it we can use a quick deno script by creating a
index.ts
This will return an error with the message
You do not have permissions to read from this Topic
But if we change our code to pass along an authenticated user, then we will be able to connect and receive / send messages.
Do not forget that RLS policies can use other tables in them so this will give you all the flexibility you need to better fit your use case but be aware of the performance impact of heavy RLS queries or non-indexed fields.
Migrating from Public Channels
On connect, you need to send in the configuration that the channel will be
private: true
Client library
We’re working on the
next
version actively so we can provide a good developer experience.Please check the latest
next
version at https://www.npmjs.com/package/@supabase/realtime-js?activeTab=versionsThis library as changed the configuration settings to add
private: true
on channel connect to determine if the user will be connecting an RLS checked channel.How it works
Connection context
When you connect with Realtime we set a connection configuration with your JWT, Topic and Headers using the following query:
This query is only run when you connect to a topic.
We’re also providing a new function to easily fetch the
realtime.topic
configuration withApplying RLS Policies
To achieve RLS checks on your Realtime connection we created a new table in the
realtime
schema to which you will be able to write RLS rules against it to control your topics extensions.You won’t see any entries recorded in this table as we rollback the changes made to test out RLS policies to avoid creating clutter in your database.
Beta Was this translation helpful? Give feedback.
All reactions