Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, and Storage.

Supabase

whoever is in charge of the ui, could i get my PR's reviewed please? :)

They'll be reviewed, be patient. The team are taking the weekend off I believe.

The process takes time, just wait a bit as the team have had a very busy week.

Sorry I’m not use to all these abbreviations, it’s probably better to write in long form as many people don’t know what the abbreviations mean

Autocomplete mistake, it’s corrected now

Yeah it happens to me. I’ve been copying batches of 100 docs from an api and it’s been taking a ton of time and, surprisingly, bandwidth too

If you make an GitHub issue I’ll add my details to it too

is it safe to be making calls directly to supabase from the client side via the js SDK? I _think_ it's cool given that I'm using a public key and a JWT (in addition to RLS on tables) for each call. But I'm not sure how I feel about showing the location of supabase url

is the DB url and public key enough to wreck havoc?

should these calls be routed through BE calls?

if your policies are set up correctly, no

Both the URL and anon key can be exposed in the front-end. The anon key will adhere to row-level security policies.

Technically, someone could grab both of those things from the network tab of a browser and use them elsewhere, but if you have RLS policies that check `auth.uid()` in place, they won't be able to access the tables unless they've got an authed user.

You've got a few options:
 - Accept it
 - Route requests through an API, which introduces more complexity as you have to proxy requests back to the front-end (including headers)

If you were self-hosting, you could definitely setup CORS policies - I've not personally dug into that, but I know there's some in place in the self-hosted version, though I think it's just `*` / all origins

Thinking about it, CORS might even be limited to the site url in auth settings - not 100% sure on that, maybe one of the team can clarify

and what affect would that have if true? Only calls from the `Site URL` declared in settings would be permitted?

Assuming I'm correct, yeah, that would be the case. Looking through the source for the gotrue repo now to see if I can confirm

Just checked, and the CORS handler (https://github.com/supabase/gotrue/blob/master/api/api.go#L200) doesn't specify an `AllowedOrigins` parameter (as per https://github.com/rs/cors#parameters), so it looks like all origins are allowed :\

maybe there's good reason for that API design? It'd be interesting to hear the case for it

I'd also be interested to hear the reasoning too.

I've opened a thread - <#871172819201953822>, but it might be worth opening a github discussion on it if that doesn't get any replies

I’d say CORS is irrelevant for Supabase, security wise

A cross origin would need to obtain a token anyway to send it along the request.

DoS wise, there’s more effective ways than using users’ browsers

As for the security of client side calls, with proper RLS you’re fine. However, I stay away from client side mutations

with ocasional inserts/updates for super simple stuff (an example is a voting system for comments).

Another example, where I would never do client side inserts, is the comment itself. That’s something that requires plenty of logic that won’t work at database level.

So yeah, go head on for direct selects with RLS, and proxy other operations through your backend for proper sanitization (unless it something simple where it’s super easy to add constraints).

DELETE is another operation you could safely allow directly and handle it via RLS, since generally you won’t have complex conditions for deleting stuff

**generally**. Obviously depends a lot on your architecture and app.

That's a fair point, and I thought about it a little more after I woke up today. Security is just one aspect of it, albeit a very important one, and you're correct that a token would need to be obtained, which would be impossible due to the redirect URI in place.

My consideration isn't really DoS since that's an entirely separate concern. Likewise, good RLS policies are essential in any PG environment so I'm not concerned about how those tie in with CORS.

My concern is really for tables where you've got truly public data (e.g. pricing for products) that you might not want being displayed elsewhere than your website. If you've got a bunch of random websites feeding on data from your database, that's resources being dedicated to serving those queries which could be better used for serving legitimate queries from authorised sources.

I guess I'd just like the option to be able to say 'only these websites can access the database via REST'. It won't stop a server-side environment, but it could certainly reduce the number of requests that shouldn't ever hit your database in the first place.

I usually hate the idea of making it easy for people to use my data directly, but in the end, it doesn’t matter

Chances someone would do it that way are slim, and they would just proxy data if they really had to

But it would indeed be nice to have the option to just say no

Also, this would be best implemented at Kong level rather than gotrue server, since you’d want CORS for all api requests

Could also probably easily allow per component CORS settings since every Supabase component sites on a different path

wondering if I should be routing these calls through a serverless fn. But the downside there is doubling up on network calls

<@!375459781965512714> supabase doesn't have Supabase Functions (yet) but will be very soon, are you required to make calls directly to supabase without the library?

just didn't know what the security implications were there

im not entirely sure honestly but i'd suggest using the library anyway since its there and already integrated :)

thanks but that doesn't really help address the security concerns

i don't think exposing the url as is, is a big issue, but its another layer that is exposed, if they don't have the URL, then they need to figure out 2 things in order to be malicious, the URL and the key, but if they have the URL, then they only need to figure out the key. thats just the way i think of it

now im sure in certain instances you can get the URL *anyway* but might as well not hand it to them

Hi do we have example for roles and permission?
and what the right structure for it?

I think supabase already has examples for that. Look at `auth/policies`

Will the old postgress dbs om 12.x versions upgraded to 13.3?
For paid or few customer's?

Does anyone know about it.

Or is it something we can do from dashboard

New projects from now on will automatically use newer version of posgres that Supabase support (as of today, **13.3 is available for all users on new projects**).

Yes I know this, 
What about the old ones?

Does anybody know what it means when the free tier pauses after one week inactivity? Thanks for your efforts.