Advanced Row Level Security (RLS) Policies // Authorization Deep Dive
Вставка
- Опубліковано 19 лип 2024
- Row Level Security (RLS) is a way to implement Authorization in a PostgreSQL database. It automatically denies all select, insert, update and delete requests, unless a policy is written to allow them. In this video, Jon Meyers goes deep with RLS policies, showing how to enforce access rules across related tables.
Full Email Client playlist: • Build an Email Client ...
Row Level Security (RLS) in Postgres is a powerful feature that allows fine-grained control over which rows in a table can be accessed by different users. By defining policies on tables, you can restrict the visibility and modification of rows based on the attributes of the current user or other conditions. This is particularly useful in multi-tenant applications where you need to ensure that users can only see and manipulate data that belongs to them. RLS policies can be applied to `select`, `insert`, `update`, and `delete` operations, providing a flexible and secure way to enforce data access rules directly at the database level.
00:00 Introduction
01:01 Overview of users schema
02:53 Setting up a relationship across tables in different schemas
05:10 Creating a Trigger Function to insert a new user
09:26 Enabling Row Level Security (RLS)
10:28 Enabling security_invoker to enforce RLS on Views
11:55 Enforcing RLS policies for `select` from related tables
17:03 Writing a `delete` policy across related tables
20:27 Enable `insert` across related tables, using an RLS policy
22:59 Going deeper with RLS
💻 Videos to watch next:
▶ Implement Authorization using Row Level Security (RLS) with Supabase (Step By Step Guide): • Implement Authorizatio...
▶ Use AI to enable and generate RLS policies for Postgres with Supabase: • Use AI to enable and g...
▶ Learn Postgres (playlist): • Learn Postgres
👇 Learn more about Supabase 👇
🕸 Website: supabase.com/
🏁 Get started: app.supabase.com/
📄 Docs: supabase.com/docs
🔔 Subscribe for more tutorials and feature updates from Supabase: / @supabase
📱 Connect with Us:
🐙 Github: www.github.com/supabase
💬 Discord: www.discord.supabase.com/
🐦 Twitter: / supabase
▶ Instagram (follow for memes): / supabasecom
ABOUT SUPABASE:
Supabase is the open source Firebase alternative. Supabase provides a full Postgres database for every project with pgvector, backups, realtime, and more. Add and manage email and password, passwordless, OAuth, and mobile logins to your project through a suite of identity providers and APIs.
Build in a weekend, scale to millions.
#Supabase #AppDevelopment #RealtimeApps #DeveloperTools - Наука та технологія
Please do a video on including additional data from the public schema in the session
That’s a good one! Will add it to the list! 💯
superb videos, content and delivery, hope supabase will continue to rock!!!
It definitely will! Glad you enjoyed the video! 🙌
Great! Love the content ! Thanks
Thanks! Glad you enjoyed it! 🙌
Thanks! Glad you enjoyed it! 🙌
Is there a good naming pattern for the policies? I have like 70+ tables and Somehow I write "users can read" "users can select", "users can see" … I ended up to copy select / update / ... so that is it at least a bit unified
Yeah, can get a little out of hand! I would recommend using the name to describe the policy to make it easier to parse later - “authenticated users can select their own todos” rather than “select todos policy”
you should be using select with auth.uid()... need a video on policies and speed
Yep, good call! This would be more efficient!
I created schemas to organize my tables in Supabase, but I am unable to load them in FlutterFlow. On the schema screen in FlutterFlow, only the tables in the 'public' schema appear. What configuration should I make in Supabase so that these schemas I created appear in the API?
@dshukertjr any ideas?
Strange, I don't have the "definition" button on the view in the table editor section. Have you the same issue ?
Oh weird! I thought this was rolled out to all projects. If you submit a support ticket to supabase.com/support someone can take a look 👍
what is id, supabase_id, and recepient_id!
id is the primary key of the table, supabase_id is the foreign key from another table, recipient_id is the user the email is sent to. The reason this is so convoluted is because it is adding authorization to an existing application and schema.
Check out the playlist in the description if you want some more context 👍
Supabase getting overcomplicated..... Let me give surrealDB a shot
It’s not Supabase being complicated, it’s Postgres being powerful 😂
@@BenjaminMichottenailed it!