Realtime Broadcast and Presence Authorization

[filipecabaco]

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.

CREATE POLICY "presence sync and broadcast listen to authenticated users"
ON realtime.messages FOR SELECT
TO authenticated
USING ( true );

CREATE POLICY "presence track and broadcast send to authenticated users"
ON realtime.messages FOR INSERT
TO authenticated
WITH CHECK ( true );

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:

-- Set permission for authenticated users to only listen for Broadcast messages
CREATE POLICY "authenticated can listen to broadcast only on their topics"
ON realtime.messages FOR SELECT
TO authenticated
USING ( 
	exists(
      select 1
      from public.rooms r join public.rooms_users ru on r.id = ru.room_id
      where ru.user_id = auth.uid()
        and r.name = realtime.topic()
        and realtime.messages.extension = 'broadcast'
  )
);
-- Set permission for authenticated users to only write for Broadcast messages
CREATE POLICY "authenticated can write to broadcast only on their topics"
ON realtime.messages FOR INSERT
TO authenticated
WITH CHECK ( 
	exists(
	  select 1
    from public.rooms r join public.rooms_users ru on r.id = ru.room_id
    where ru.user_id = auth.uid()
      and r.name = realtime.topic()
      and realtime.messages.extension = 'broadcast'
  )
)

Testing Authorization

Now to test it we can use a quick deno script by creating a index.ts

// Run with deno run --allow-net --allow-env --allow-read --allow-ffi index.ts
import { createClient } from "npm:@supabase/[email protected]";
const url = "https://<project_ref>.supabase.com";
const apikey = "<api_key>";

const client = createClient(url, apikey);

const channel = client.channel("channel_1", {
  config: { broadcast: { self: true }, private: true},
});
channel
  .on("broadcast", { event: "test" }, (payload) => console.log(payload))
  .on("presence", { event: "join" }, (payload) => console.log(payload))
  .on("presence", { event: "leave" }, (payload) => console.log(payload))
  .subscribe((status: string, err: any) => {
    if (status === "SUBSCRIBED") {
      console.log("Connected!");
    } else {
      console.error(err);
    }
  });

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.

import { createClient } from "npm:@supabase/[email protected]";
const url = "https://<project_ref>.supabase.co";
const apikey = "<api_key>";

const client = createClient(url, apikey);

await client.auth.signInWithPassword({
  email: "<email>",
  password: "<password>",
});

client.realtime.setAuth(
  (await client.auth.getSession()).data.session.access_token
);
const channel = client.channel("channel_1", {
  config: { broadcast: { self: true }, private: true },
});
channel
  .on("broadcast", { event: "test" }, (payload) => console.log(payload))
  .on("presence", { event: "join" }, (payload) => console.log(payload))
  .on("presence", { event: "leave" }, (payload) => console.log(payload))
  .subscribe((status: string, err: any) => {
    if (status === "SUBSCRIBED") {
      console.log("Connected!");
    } else {
      console.error(err);
    }
  });

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=versions

This 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:

SELECT
	set_config('role', $1, true),
	set_config('realtime.topic', $2, true),
	set_config('request.jwt', $4, true),
	set_config('request.jwt.claims', $6, true),
	set_config('request.headers', $7, true)

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 with

SELECT realtime.topic();

-- Usage example
CREATE POLICY "authenticated users can only write to topic named foo"
ON realtime.messages FOR INSERT
TO authenticated
WITH CHECK ( realtime.topic() = 'foo' );

Applying 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.

[psteinroe]

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.

[chasers]

This is on prod right now so play with it and let us know how it feels.

jfyi you can POST to Broadcast like:

curl -X "POST" "https://REF.supabase.co/realtime/v1/api/broadcast" \
     -H 'Authorization: Bearer ANON_OR_SERVICE_OR_AUTHENTICATED_ROLE' \
     -H 'apikey: ANON_OR_SERVICE_ROLE' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "messages": [
    {
      "event": "broadcast",
      "payload": {
        "message_text": "Hi there!",
        "from": "chasers"
      },
      "topic": "messages"
    }
  ]
}'

[chasers]

Also to reiterate: this won't break anything for you UNTIL you create a channel. If you create a channel with the same name as one you're using already it will start checking RLS for it.

[psteinroe]

@chasers looking into migrating back to realtime with rls now. just to be sure: how is the channel policy related to the broadcast policies? the former is just for managing channels themselves right? So in my use case where I want to send a subset of the WAL data as a service role client to the frontend, I need to create a channel for every socket io room, and create a policy for select broadcast to check whether the user can receive messages via the channel?

I compare it with my current socketio-based approach where I use rooms to easily authorise. A room maps to a channel in realtime I guess. Is there any way to auto-create a channel when it does not exist yet? Channels are quite dynamic in my case, and I cannot send the create channel request every time a new message needs to be processed.

[GaryAustin1]

Sort of related on setting up channels...
Do the API calls just add entries to the realtime schema tables, or is there something in the realtime server itself?
The approach I'm looking at it would be best to just create rows in the channel and broadcast table with SQL for the channels.

[chasers]

Replying for comms, this is on prod and officially public alpha. Please play with it!

[GaryAustin1]

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.

[silentworks]

If this happens only on connect would this mean that if the app owner decides to change a RLS rule while someone already has a websocket connection going they wouldn't be affected by this rule change? I'm thinking of someone writing a rule to prohibit users with a certain role from accessing some broadcasts, but then later on the business requirements change and the user is now given access to that broadcast.

[filipecabaco]

for that we will need to advice users to keep expiration tokens low and at a later stage we need to add that "kill all connections in channel X" functionality so they have a quick way to ensure their rules are applied

[GaryAustin1]

I'm just using changes on a single client. Without the client running I have 1 connection from supabase_admin role.
When I start the client it goes to 14 running the realtime query I've seen it do for polling.

Another user reported this here: https://discord.com/channels/839993398554656828/1228290205690368010 and I am confirming it seems odd mainly as I don't recall seeing this level of connections before, but I could have missed it.

[psteinroe]

I can also confirm that something is wrong with connections - we received a few "max connection limit reached" today which never happened before.

[chasers]

Handled in our contributor Slack but for comms, this is fixed.

Realtime has a pool of connections to your db used for various purposes. You can see which connections Realtime is using with the query:

select usename, application_name from pg_stat_activity where application_name ilike 'realtime_%';

Realtime uses the application_name realtime_connect to check RLS policies as clients connect to a Channel or hit the Broadcast API endpoint.

Now, the default for this is 1 connection (decreased from 5) and it is configurable. With more Channel joins or Broacast POSTs per second you will need more connections available to check RLS policies.

Contact support to increase this config.

[filipecabaco]

@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.

[GaryAustin1]

What are the 3 options?

I like the overall approach of RLS channels. I'd prefer they create themselves IF they meet RLS to do so as an option. This use case is where you have a channel for a chat room or per user and saves having to do a separate operation to add to the tables.

Having two tables involved makes things more difficult. Do you need an overall channel table versus just the table for broadcast (or in the future other things).

As discussed working from a statement trigger (or row trigger) with a direct Notify to the realtime server would be a big benefit over using PG_net to call the REST API. (of course pending performance numbers of Notify versus an async HTTP request). My assumption is Notify is similar performance to replication sending data, but I don't know that.

But you really need at least a simple case for broadcast channels to secure them is probably the most important thing for the general user base.

[filipecabaco]

In the doc you have three sections (Option 1 / Option 2 / Option 3) that differ the RLS rules applied to reach the same goal.

From your comment I think that you might be leaning more towards Option 2 correct?

[GaryAustin1]

Yes 2 is much better than 1 especially if you are only doing broadcast. As we found the RLS was difficult to debug and the fewer the tables the better. I also think a separate table for each feature is fine (like 1 but without the channels table) as simpler RLS than 2 and you know what feature(s) you are using.

But I'm mainly looking for keep it simple to cut down user confusion and 1 and 3(not studied closely) seem more confusing on getting the RLS right.

[psteinroe]

I am with @GaryAustin1 here. for me, the most important requirement is flexibility. a use case where a lot of flexibility is required is a chat app. with 2, I guess I would just create one channel per conversation. the two other options feel like I need to adhere to a certain structure unnecessarily. but I did not think about this long enough yet.

[filipecabaco]

https://github.com/orgs/supabase/discussions/22484#discussioncomment-9744342

[aparx]

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.

[filipecabaco]

We backtracked a bit and now we want to define better what users want from the RLS policies, we're going to finish this feedback loop this week so we can change the current implementation and bring it back with some extra changes.

As we change we will change this discussion as this is our main spot for communicating changes to this feature at this point in time.

[aparx]

When are you guys expecting a release of this? Since I am building quite a large application at the moment and need to build an abstraction around the currently available realtime of supabase, thus I need to count on one of those options you mentioned in your thread.

[filipecabaco]

It's always tricky to set a timeline but the biggest elements of the implementation are done and now it's refining this RLS experience.

Meaning that in the coming weeks we would be able to enable this for your account but can't set a definite timeline as we want to ensure the best experience.

[aparx]

Understandable 👍

[filipecabaco]

https://github.com/orgs/supabase/discussions/22484#discussioncomment-9744342

[filipecabaco]

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.

[psteinroe]

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
);

[filipecabaco]

Yes, I want to release the minor version today which would streamline it as this is done automatically if I recall correctly

[psteinroe]

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:
Messenger App. Chats are organised in inboxes. Access to a chat is controlled via access to inboxes.

• In Socketio, rooms control who can see what. This is backend-only. The implementation of this is hidden in the frontend. When the client connects, it is put into the rooms it can see. In the frontend, I just subscribe to inbox events and everything is routed correctly based on rooms.
• In realtime, there are just topics. Topics must handle both, auth and routing. This means that instead of subscribing to inbox events in the frontend, I now need to subscribe to the events for every single inbox. the frontend must be aware of how authentication is set up. This means I need to 1) fetch all inboxes the user has access to and subscribe to every single one of them and 2) need to change the frontend if I change how conversation auth is setup.

Am I missing something, or is this how its supposed to be designed with the new realtime auth?

[filipecabaco]

from my understanding we have different "primitives" to which we are bounded:

• socketio is event bound and fans out to multiple topic
• realtime is topic bound that fans out multiple events

so in your scenario where a person gets pinged for new messages you would need a notification topic on realtime where you broadcast events for all authorized rooms of a given user and then on click you would connect to the specific topic to receive further messages (this in a slack like app)

we could potentially support a "*" topic where you get all events that your user can listen to but that is yet to be implemented but it would be a useful one 🤔

[psteinroe]

thanks for the quick reply! I see. The difference in primitives is a very good hint on how to design for Realtime coming from socketio! But the * topic would be very useful indeed! It would enable the frontend to just subscribe to everything the user needs to subscribe to globally.

[filipecabaco]

I will try to take a look on what work we would need to achieve it 🤔

[GaryAustin1]

I was testing the new JS code and I'm sure this is known but probably will want to document it.
If you change the RLS on a channel that has clients connected from something that includes them to something that doesn't (like anon to authenticated) they will still receive messages until they disconnect. It may also be true that when their jwt refreshes they probably get bumped, but I did not check it.

This makes sense, but is sort of a security thing to think about if you change RLS.

[GaryAustin1]

It would be useful for private broadcast to include the sender's sub claim and role. If doing a channel per user by their id, that could be used for private conversations or database/server messages for user specific info. Having the secure user id for the sender would prevent spoofing as sending in payload would not be secure.

[GaryAustin1]

Also as the REST broadcast endpoint has to check RLS for each send it might be good to not bother with checking the message table if role in the jwt is service_role. It will bypass anyway, but is an extra db read for every message.

[dungeon2567]

It would be useful for private broadcast to include the sender's sub claim and role. If doing a channel per user by their id, that could be used for private conversations or database/server messages for user specific info. Having the secure user id for the sender would prevent spoofing as sending in payload would not be secure.

I really need that

[dungeon2567]

Any update?

[filipecabaco]

This is done, you have access to the JWT claims on RLS policies 👍

[filipecabaco]

FYI we've moved the feature to Public Beta
https://supabase.com/blog/supabase-realtime-broadcast-and-presence-authorization

[kaceycleveland]

While trying to debug authorized real time calls, I noticed that sending private: true calls from the local supabase dashboard was not available while it was available on the hosted instance. Is there plans for adding it to the local dashboard?

Related bug that this would have helped with for debugging:
supabase/supabase-js#1274

[filipecabaco]

Will check this Monday as it should already be available 🤔 need to check the versions of.the docker images...

[filipecabaco]

We got two PRs merged yesterday to tackle this issue:
supabase/cli#2711
#29524

was just an older image being used for Supabase Studio. This will be available on the next release of the CLI and/or self hosted

[daveycodez]

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.

[w3b6x9]

@LeakedDave thanks for pointing this out.

Just want to clarify that this does not apply to Realtime Postgres Changes as authorization is handled on a table by table basis and in accordance with RLS policies on those tables.

As for Realtime Broadcast and Presence, our Realtime team is currently working on the option to disable Realtime public channels for a project and that should reach production shortly. When that is available, users can opt into only private channels.

In the interim, we recommend new projects and existing projects using public channels to migrate to use private channels. Over time, we'll make private channels the default but during the transition we'll clearly document and alert users that they should use private channels.

As far as pricing, Free projects are capped and never charged and paid plans have a spend cap so users can specify their Realtime concurrent max connections and number of messages usage and not be surprised when it comes to the bill.

If anyone is surprised by either their Realtime usage or bill please submit a ticket and we'll investigate.

[daveycodez]

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 ->
5 Million included
then $2.50 per Million

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.

@filipecabaco

[w3b6x9]

@LeakedDave thanks for the breakdown. See https://github.com/orgs/supabase/discussions/22484#discussioncomment-11170948.

[cmolendijk]

@w3b6x9 any update on the function of disabling the realtime public channels for Realtime Broadcast and Presence?

[daveycodez]

The Supabase team doesn't work on safety features to protect its customers from excessive egress and unexpected bills. They do these launch weeks for useless AI products instead. They've ignored calls for Rest API rate limiting for years and they still have all Supabase projects exposed to realtime abuse. This should've been addressed within 48 hours.

I highly suggest migrating to Better Auth and Neon.

[filipecabaco]

Hi,
Yes we already have the flag to allow usage of only private channels, we are working on the steps to allow it to be enabled/disabled from Supabase Studio 👍

[cmolendijk]

Great to hear. Is there a way we can already use it without Supabase studio to test it. For example a local flag or db query to set the flag?

[filipecabaco]

Yes you can set the flag called "private_only" in local hosting on your tenant if you check the _realtime schema 👍

In production we still are not changing it as certain operations would reset the flag and become a problem ... For example if your project pauses the flag would be reset leading to an extremely frustrating experience