2 ms·

Others have pointed out that this is more about Supabase than it is about "vibe coding." As someone just learning to use Supabase myself, the 2 biggest pieces o

Others have pointed out that this is more about Supabase than it is about "vibe coding." As someone just learning to use Supabase myself, the 2 biggest pieces of advice I have are: 1. Put anything that you don't want to be accessible by anon in a schema other than "public." This seems obvious, but the public schema is Supabase's default behavior. Supabase's official reply about this question is "I guess you can, but don't worry, RLS." However, security is an onion. Put up as many barricades as you can. If I was king of Supabase, I would err on the side of security. 2. Login to Supabase Studio, set your role to "anon" instead of "postgres" and click on every single table and view that should be private, and make sure there are no results. Supabase could do a lot better about communicating this, and it would require no breaking changes unlike this disaster[0] which requires hacking your historic migrations! [0] https://github.com/orgs/supabase/discussions/34270 https://github.com/orgs/supabase/discussions/34270

kiwicopple 1y ago
(supabase ceo) > Supabase's official reply about this question is "I guess you can, but don't worry, RLS." Here is a more representative view of our official reply: https://supabase.com/docs/guides/database/hardening-data-api https://supabase.com/docs/guides/database/hardening-data-api To avoid both 1 and 2 I would suggest creating a `private` schema. We are now in the planning stages to make this the default
- consumer451 1y ago
  > We are now in the planning stages to make this the default This is excellent news! I apologize for my "disaster" wording. I had to eat some hours for that, and I am a bit salty. This was a tough thing technically for you guys, and it's likely more about future users. I get it. However, hacking my old migrations did feel very icky. All that aside, I would like to genuinely thank your team for reading my reddit comment about my argument for MCP --read-only, and only a couple of days later coming back with ~"Yeah, that actually makes sense, we are doing it." On HN, we are used to YC-funded CEOs chiming in sometimes, but you guys created a feature based on my rando reddit comment, because it made sense. That's an org I want to work with. I should have made my original comment more accurate about my feelings.
  - kiwicopple 1y ago
    > reading my reddit comment about my argument for MCP --read-only it was great feedback, thank you!

kiwicopple 1y ago

(supabase ceo) > Supabase's official reply about this question is "I guess you can, but don't worry, RLS." Here is a more representative view of our official reply: https://supabase.com/docs/guides/database/hardening-data-api https://supabase.com/docs/guides/database/hardening-data-api To avoid both 1 and 2 I would suggest creating a `private` schema. We are now in the planning stages to make this the default

consumer451 1y ago
> We are now in the planning stages to make this the default This is excellent news! I apologize for my "disaster" wording. I had to eat some hours for that, and I am a bit salty. This was a tough thing technically for you guys, and it's likely more about future users. I get it. However, hacking my old migrations did feel very icky. All that aside, I would like to genuinely thank your team for reading my reddit comment about my argument for MCP --read-only, and only a couple of days later coming back with ~"Yeah, that actually makes sense, we are doing it." On HN, we are used to YC-funded CEOs chiming in sometimes, but you guys created a feature based on my rando reddit comment, because it made sense. That's an org I want to work with. I should have made my original comment more accurate about my feelings.
- kiwicopple 1y ago
  > reading my reddit comment about my argument for MCP --read-only it was great feedback, thank you!