所有权

在 Supabase 存储中创建新的桶或对象时，会自动为桶或对象分配一个所有者。所有者是创建该资源的用户，其值来源于 JWT 中的 sub 声明。我们把 owner 存储在 owner_id 列中。

🌐 When creating new buckets or objects in Supabase Storage, an owner is automatically assigned to the bucket or object. The owner is the user who created the resource and the value is derived from the sub claim in the JWT. We store the owner in the owner_id column.

使用 service_key 创建资源时，所有者不会被设置，资源将被任何人拥有。通过仪表板创建存储资源时也是同样的情况。

🌐 When using the service_key to create a resource, the owner will not be set and the resource will be owned by anyone. This is also the case when you are creating Storage resources via the Dashboard.

存储模式有两个字段表示所有权：owner 和 owner_id。owner 已弃用，将会被移除。请改用 owner_id。

🌐 The Storage schema has 2 fields to represent ownership: owner and owner_id. owner is deprecated and will be removed. Use owner_id instead.

访问控制 #

🌐 Access control

仅仅拥有一个资源本身并不能提供任何访问控制。不过，你可以通过对归属于其所有者的存储资源实现访问控制来强制执行所有权。

🌐 By itself, the ownership of a resource does not provide any access control. However, you can enforce the ownership by implementing access control against storage resources scoped to their owner.

例如，你可以实现一个策略，只允许对象的所有者删除它。为此，检查对象的 owner_id 字段，并将其与 JWT 的 sub 权限进行比较：

🌐 For example, you can implement a policy where only the owner of an object can delete it. To do this, check the owner_id field of the object and compare it with the sub claim of the JWT:

1
create policy "User can delete their own objects"
2
on storage.objects
3
for delete
4
to authenticated
5
using (
6
    owner_id = (select auth.uid()::text)
7
);

使用 RLS 策略是一种执行访问控制的方法。你也可以在服务器代码中通过遵循相同的模式来实现访问控制。

🌐 The use of RLS policies is one way to enforce access control. You can also implement access control in your server code by following the same pattern.