课程: Supabase Essential Training

Authorize data

课程: Supabase Essential Training

开始一个月试用 购买团队方案

Authorize data

“

- [Instructor] Once a user is authenticated you can then further control what they can and cannot do through authorization. Supabase makes authorization possible through SQL queries. Let's create a new table and then apply an authorization to it. I'm here in the public schema of Supabase, and I'm clicking New table. This way this new table is going to be a part of our API. And I'm going to call this table private_notes. Now, just for a moment I'm going to disable RLS. Even though this is called private_notes, I'm going to disable this just to show you what happens. What happens is we get this modal window telling us that the table will be publicly readable and writable, and then all requests will be accepted and no authorization policies will be enforced. We definitely want to apply row-level security to this table because these are going to be private notes, so let's cancel out of this and continue creating the table. So, we have an ID, we have created_at. I'm going to switch the ID to a UUID. And then we're also going to leave the created_at column as is. Then we're going to add a column for note, and we're going to make this a text column. There should be some content in the field, so we are going to make this required and uncheck Is Nullable. And now we're going to also add a user_id. I'm also going to make this a UUID. And then I'm also going to make this required. Now, one thing we can do is we can link this user_id to the users table in the auth schema. So, I'm actually going to go to the auth schema rather than public and then reference the users table there. So, this way we're going to link public.private_notes.user_id to auth.users.id. And this is just confirming that we're going to be using UUIDs in both places, and I'm going to click Save. So, now we have a foreign key relation to the auth.users table. Note that auth, because it is not in the public schema, is away from our API. And we can still reference it from here, but we are not able to query it directly from the API. I'm now going to click Save, and that has created our private_notes table. Now, at the moment because RLS is enabled, only the service user can read from or write to the table. And while that can useful in certain cases where you don't want users to have direct access to the data, it's not useful for this specific use case. We want to support private notes for users, so I'm going to add that policy now. Let's go to Add RLS policy and private_notes comes up. We're going to create a policy for private_notes, and we're going to do an INSERT for authenticated users only. And this should work for allowing people to add notes, but we really want people to only add their own notes. So, let's do this as an enable insert for users based on their user_id. This way it's going to check the user_id first and then allow the INSERT. This user_id has to match the ID of the user that's logged in. That way I can't just log in and supply someone else's user ID and create a note on their behalf. So, we're going to save that policy. This enable insert for users based on their user_id is going to allow people to add their own notes, but we also need to let them read their own notes. For that we're going to need to create another policy, so let's click that button. And let's find a template here that allows them to do that SELECT. Right here we've got enable users to view their own data only and perfect, this is exactly what we want. It's going to look for the user_id of the person that's logged in and then compare that to the user_id of the record. And notice this time it's for SELECT rather than INSERT, and it's going to target the authenticated role. Next, let's add some private notes for a user. But first, let's make sure we have users that are available. At the moment I don't have any users in this Supabase instance so I'm going to add one. Let's go to Add user and Create new user. Let's add an email address here, and also give a password for this user. And then before we leave this screen let's grab this ID. So, there's a little Copy button here, we're going to click that, and that will copy it to our clipboard and we'll be ready to use this. So, let's go back to the Table Editor, and I'm going to go to private_notes and I'm going to insert a new row. We're going to let the ID auto-populate here for the private note. The note here is just going to read Super secret. And then I am going to paste in that ID. There's also a way to select a record if you need to. And now I'm going to click Save. And now that has linked this private note to this user. So, right now I am in the Postgres role, which is also the service user role, so I can see everything. But if I switch this role to anonymous that record disappears. That's because the RLS policies are being applied, and only the service user and the logged in user are able to see this. I'm now going to switch to the user role. So, I'm going to click authenticated role, and then I'm going to select this email address and click Impersonate. And now I am able to see this record again because I am impersonating the user that is authenticated. Row-level security and PostgreSQL is a powerful way of configuring the authorization of your Supabase application. Remember to always enable RLS for your tables in the public schema to prevent them from being readable and writable without restrictions.

内容