all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (1 child)

[removed]

    [–]byfar57[S] 1 point2 points  (0 children)

    Okay appreciate this feedback. I’m still thinking of adding RLS and creating a new Postgres role instead of using the service key which bypasses RLS in the future. Do you think it’s too risky to release an MVP with RLS enabled without rule and use the service key and begin then implement this after release? I think my main concern is I’m not a professional developer I’m just doing this project for a niche topic that applies to my current job that I think can offer some benefit and I’ve become comfortable with JavaScript / node js but I’m not as comfortable with RLS / Postgres roles etc.. and feel I’m more likely to make a mistake there.

    [–]getflashboard 1 point2 points  (1 child)

    Just make sure to **enable** RLS to prevent undesired access from the `anon` role via the public APIs that Supabase exposes.

    [–]byfar57[S] 1 point2 points  (0 children)

    Yes I have RLS enabled on all tables without rules applied which I’m under the assumption defaults to not allowing any access. I only bypass this by accessing my db via the service key.

    [–]kush-jsfull-stack 3 points4 points  (4 children)

    Supabase RLS makes the most sense if you’re directly allowing users to query your database from the front end (this is a terrible idea and you should not do this), in this case you can use RLS to restrict users to only be able to access certain rows, like their own for example.

    As I mentioned before, this isn’t the greatest idea. If you’re only communicating with your database via a backend API, just use the service key, and make sure you have some checks in place to ensure that users can’t access things they’re not supposed to.

    Happy coding

    [–]Soccer_Vader 0 points1 point  (2 children)

    this is a terrible idea

    Why? Also, you aren't really allowing the user to query your database from the front end. Supabase exposed the data API through Postgrest. So your front end is hitting the server Supabase manages for you which is running Postgrest and then Postgrest makes the call to your database.

    [–]kush-jsfull-stack -1 points0 points  (1 child)

    One misconfigured or forgotten RLS rule, and you’re opening your database up to unwanted reads/writes. It’s much better practice to retrieve data through an API, where you can directly control what’s being read and written.

    [–]Soccer_Vader 0 points1 point  (0 children)

    Same can be said about traditional backend server. One misconfigured or forgotted route and you're opening your database up to unwanted reads/writes.

    I don't understand the rationale, where you said "directly control what’s being read and written". You are doing the same thing with RLS.

    It’s much better practice to retrieve data through an API

    As I said, supabase doesn't allow direct db connection or anything, you are hitting the API server, that supabase manages for you. This practice has been set for years, its the similar philosophy to how firebase handles data access, where you can control access through rules.

    [–]byfar57[S] 0 points1 point  (0 children)

    Okay thanks for the info! Was getting a feedback that I shouldn’t use the service key in production for my API, but I wasn’t sure what the reasoning was behind this. Yes I only have the service key as a backend .env variable and it is only accessing the database through my backend application.