Please add Python help channel

Guys, I love supabase

and am happy to have just upgraded to a paid plan

but I just wanted to say that I think this screen needs improvement

after going through the upgrade flow I reached this screen

so I pressed the big green continue button... and nearly downgraded my plan to the free tier 🙂

don't know if you control that page or it is just stripe's, but not the best UX imo

Yeah, that's the stripe checkout/manage plan page. There's very little control over that page except the colours (and only limited support there)

Maybe just change that button's colors

But understood!

Happy to be a paying customer

And I don't know when you added it but I love the simplicity of the reporting page

Could we get a policy document system that describes the policies for postgres tables? Kinda like firestore rules. Would make development faster initially

Been using the dashboard a lot lately, I have found that it is really hard to know the position of the scroll bar cause of the dark background. Is there a reason it was made dark and is there a possibility to turn it to the default scroll bar or at least with a white background?

Can you provide a link to what this looks like please?

I agree, it's really not ideal - it's especially bad when you have multiple projects like you have in your screenshot. We'll try and move away from using the Stripe Checkout although the ETA on that is unknown.

I'll fix that now - we've been meaning to for ages!

done 😄

The documentation concerning auth and SSR must be improved: explain how auth work with local storage and cookies and have more examples, not only with React but also with Vue for example

Can you elaborate on this more ? Keen to hear more

Might be best to open a feature request in the gotrue (supabase auth) repo. Others can also see it and possibly pitch in and work on it. https://github.com/supabase/gotrue/issues/new?assignees=&labels=enhancement&template=2.Feature_request.md

Might be best to open a feature request in the gotrue (supabase auth) repo. Others can also see it and possibly pitch in and work on it. https://github.com/supabase/gotrue/issues/new?assignees=&labels=enhancement&template=2.Feature_request.md

We have a need for third parties to create their own Oauth2 clients for accessing our platform's data, is this something Supabase is considering? something like keycloak or ory hydra, to name a few. I understand that would be a pretty big project 😄

We've talked about offering an IDP, but it's not something that's been scoped out, or scheduled for work in the near future

Firestore has policy documents which describe access rules for documents inside a collection. You can specify a rule for read and write. You can use JavaScript inside a rule. The docs: https://firebase.google.com/docs/firestore/security/get-started The advantage of such a system in Supabase is users will not have to spend time learning about RLS and SQL policies (unless they want to). The underlying RLS and SQL policies would be abstracted away and handled by Supabase. It also would help Firebase devs transitioning to Supabase (like me) as they can "convert" their policies over. You would write SQL-like code and Supabase would translate it into actual SQL and RLS. Example Supabase policy document:

{
  match /tables/public/user_profiles {
    match /{id=**}/ {
      allow read;
      allow write: if "id" = auth.uid();
    }
  }
}

Could be translated into (my SQL isn't very good):

sql
ALTER TABLE user_profiles 
    ENABLE ROW LEVEL SECURITY;

CREATE POLICY "read"
    ON user_profiles FOR SELECT USING (
        true
    );

CREATE POLICY "write"
    ON users FOR UPDATE USING (
        auth.uid() = id
    );

Just replied above

hi just a suggestion, can we have like a "folder" type thing for our SQL queries in order for us to manage our queries easier, like trigger functions in a single folder, or a single group, views queries on another. just an idea of mine

For use in policies, create an

auth.user()

function (similar to auth.id() and auth.user_id()) that returns

public.users WHERE users.auth_id = auth.id() LIMIT 1

(probably not the right syntax but you get the intent) so that ANY attribute on the matching user record can be used in a policy.

i really love this example - maybe as a smaller step we should be documenting a few examples like yours so it's a little easier to grasp going from firestore json rules to postgres RLS

I bet a lot of your users are transitioning from Firebase (like me) so any documentation will help speed them along and boost their confidence! 🙂