like i asked before how do i implement rate limiting ?

like i asked before how do i implement rate limiting ?

Do you have a specific use case in mind? I'd like to find this out too.

It would certainly be possible to do with a dedicated table (or a column on the public users table), but more specifics on why you want to limit it, as well as your specific use case, would be helpful.

No i meant is there a solution for this from supabase itself ? i dont want to waste time setting everything up only to discover i cud have done that in a more simple way

Since requests can be done through either the REST endpoints (i.e. via the library), or to the database (e.g. via

rpc()

or something like Prisma, Sequelize, etc), it's not something that's built in as part of the stack.

mhm

Rate limiting will be possible through Kong. Check this previous discussion: https://github.com/supabase/supabase/discussions/1524#discussioncomment-746106

Omg yes

If a regular user is able to connect directly to your database with pgAdmin, you've got bigger problems than rate limiting

Uh?

The anon group isn't able to login, and it includes the

authenticator

user which is able to login (which belongs to the

anon

,

authenticated

and

service_role

groups). Ergo, there's no actual anon user, but there is a group that includes a single user. I believe it acts as a way of allowing a session to be authenticated against the correct user once credentials are validated - essentially a way of transitioning users from not-authed to either a regular

authenticated

user, or the

service_role

if it's using the service key.

Ahh

So what's the status of this now? How do we implement rate limiting with Kong?

@User Correct! You got it. Btw, this auth sequence is documented on https://postgrest.org/en/v8.0/auth.html#authentication-sequence

😂😂😂😂😂

We just send our config in http requests

So where is this done as part of my app? I’m confused.

Based on that doc, I believe that the integration would need to be done at the Kong level, which can't be customised to this degree unless you're self-hosting. I'm certainly open to the idea that I might be wrong about that though 🙂

isnt rate limiting a very common feature

So what do I do with supbase-admin-api? I built the binary and it works... so where does it run? Where do I install it?

Based on this source, I'd guess it's designed to run alongside a local hosted version of Supabase. Since 'RestartServices' function in

api/service.go

calls systemctl, I don't believe you'd be able to run it externally.

Wait its not included with supabase?

I’m not familiar with it - will need to ask Div or Inian

There's no mention of admin api in supabase docs

Yeah I’m pretty sure it’s not a stock component

Chances are that they do use it on the hosted platform, but don't expose completely custom configuration via the dashboard, either for security or performance reasons (perhaps both)

The security is just the same as the rest api for database

If you're exposing custom configuration for the routing aspect (i.e. Kong), you're allowing someone to potentially break their own service because they misconfigured it. Even if rate limiting for one project may not directly affect the performance of others, exposing custom config could lead to situations where users use a config which results in a performance hit for others. Maybe they just haven't got around to building out the UI to support it. Maybe there's another reason I'm not thinking of. It's also possible I'm completely wrong. You have to think beyond the scope of just your project because it's still a platform run on servers that are shared with other users.

Bruh if they dont know what they are doing they shudnt do it

"If they don't know what they are doing, they shouldn't do it" - Not knowing how to do something doesn't stop people from trying. The SQL query editor negates much of the need for a dedicated SQL tool, but doesn't completely replace it. You can recreate a table with SQL if you 'break' it (though, I'm not sure how you'd break a table exactly, other than dropping it entirely). You can recreate RLS policies if you mess them up, and some projects may want public tables. There's a lot of documentation on SQL. By comparison, there's significantly less resources out there on configuring Kong. You mess that up, and you either fix it, or you're left with a service that might be completely unusable. I'm not disagreeing that it would be nice to have rate limiting, or exposing more options for the architecture, but a line has to be drawn on what you allow, and you've got to be careful about how you integrate it precisely because it can have an effect on other users. If you let people just configure everything, they'll take as many resources as they can, and potentially starve other projects.

Hmm

Sticking to the specific feature: Surely rate limiting can be exposed without needing to expose complete configuration of Kong?

Hm yeah ig

Let's say they allow rate limiting at Kong level. Your example was something like 150 messages per minute. If the rate limit was exposed at the routing level, that could end up limiting it to 150 requests per minute. Not just inserts, but selects, deletes, and updates. What if a user wants to delete 150 messages? They're then prevented from sending any new messages for the next minute. Maybe it's unlikely a user will want to delete that many messages at once, but it's not impossible. Additionally, if the rate-limit config policy is set to

local

, it'll store these settings in memory. This increases memory usage, so could have a detrimental impact on an individual server.

I just don't get it

Something like this might work (untested, but should give you a rough idea of how to proceed):

sql
SELECT CASE WHEN (
    SELECT COUNT(*)
    FROM public.messages
    WHERE inserted_at >= NOW() - INTERVAL '1 minutes'
    AND sender_id = auth.uid()
) <= 150
then true
else false

That's assuming your table is called

messages

and the column you're checking is

inserted_at

, and the user ID is stored in a column called

sender_id

. This example assumes you want a maximum of 150 messages every minute. If you've got hundreds of thousands of messages being inserted every minute, it might be slow, but indexes and partitioned tables can help with that.

Mhm

supabase-admin-api

is already installed on KPS instances by default, so we can use it. I just don't understand how to implement rate limiting with it yet, but I will find out.

Looks like a juicy thread

What's kps?

kong - postgrest - supabase

Ohh 🤣

Yes I’m told it’s already running on every instance.

Hmm that's weird

You must set the apikey header to be a valid JWT token, signed by JWT_SECRET and with a claim of: role: supabase_admin

Do tell me if you find something out

Yeah I’ll try to find out tomorrow how to call it.

Yep

It’s listed in the dashboard under settings.

but it said No matching routes or somethng similar

Don’t know if you need Kong

Am just confirming

Look at the source code it should help

Oh yea i didnt think of that

yep just saw lol

could be, are you still getting 404 or scanning for the port?

Not a 404

It's running on localhost on kps, I see that: tcp 0 0 127.0.0.1:8085 0.0.0.0:* LISTEN 967/supabase-admin-

That's sad

I have admin access to ssh into my instance as supabase staff.

Ah nvm then

I'll try to get more info on this.

Thanks!

I don't understand the question

I mean can i use Hasura

I'm not familiar with Hasura, sorry 😦

and then forward the jwt cookie

auth.uid() just checks the uid inside the token

yes

Yes i saw that 😭

if you're not using postgrest, then you'd have to do the auth yourself -- you're connecting directly to PostgreSQL?

Yes

maybe you can use the same token --

current_setting

should read it? but i'm not sure

I read most of this thread

nice

I'm not really super pumped about hacks

Is there any way you could secure Realtime using GRANT (table level access) and not RLS?

and from what I've read, I think the cleanest/non hack is to have a simple table and trigger

Nope

so that's indirect realtime?

I'm sure supabase will add some configuration in the dashboard at some point

Ye

RLS on the actual table you want to protect

hmm

what's functions and real time?

Nope

so cloud functions would be configurable in the dash board in some language like node, got it.

It does

oh, i see what you mean

Features like this normally get launched in launch week, this happens every few months, I do't have an exact date on when the next one is but that's when major features get released.

@silentworks sweet! Is this an item the team is aware of?