Skip to content

Errors when creating / updating / deleting users

这些错误是你自定义用户管理逻辑中问题的正常副作用。这可能会导致返回 HTTP 500 状态码的错误，并带有代码 unexpected_failure 和以下其中一条错误信息

🌐 These error are normal a side effect of issues in your custom user management logic. This can cause errors that return HTTP 500 status codes with a of code unexpected_failure and one of the following error messages

  • 创建用户失败：数据库创建新用户时出错
  • 更新用户失败：更新用户时出错
  • 删除用户失败：删除用户时数据库出错
  • 更新用户时数据库出错
  • 保存新用户时数据库出错

调试这个错误 #

🌐 Debugging this error

此错误的常见原因： #

🌐 Common causes of this error:

  • 在 auth.users 表上设置触发器/触发器功能
  • auth.users 表上的约束没有被满足
  • 你在用 Prisma，它把 auth.users 表的所有权限都搞乱了

示例错误信息 #

🌐 Example error messages

使用错误信息中提供的提示来修复你自定义用户管理逻辑中的问题。

🌐 Use the hints provided in the error message to fix issues in your custom user management logic.

触发器/触发器功能相关的错误信息 - 触发器相关问题的解决方案

1
"error":"error update user`s last_sign_in field: ERROR: permission denied for table profiles (SQLSTATE 42501)"

约束相关的错误信息 - 关于约束相关问题的解决方案

1
ERROR:  23503: update or delete on table "users" violates foreign key constraint "profiles_id_fkey" on table "profiles"
2
DETAIL:  Key (id)=(7428a53c-75b7-4531-9ae9-1567d9c4ac0a) is still referenced from table "profiles".

缺少列

1
ERROR: column \"updated_at\" of relation \"profiles\" does not exist (SQLSTATE 42703)

搜索路径错误/名称不正确 - 42P01 相关解决方案

1
failed to close prepared statement: ERROR: current transaction is aborted, commands ignored until end of transaction block (SQLSTATE 25P02): ERROR: relation \"public.profiles\" does not exist (SQLSTATE 42P01)

🌐 Solution for constraint related issues

  • 检查 auth.users 表和另一张表之间的外键/主键关系
  • 然后更改关系的行为，并用较少限制性约束重新创建它。
  • 如果这与删除记录有关，请查看 Cascade Deletes 文档 了解可能的方法（例如使用 CASCADE / SET NULL）

🌐 Solution for trigger related issues

Supabase Auth 使用你项目的数据库来存储用户数据。它依赖 auth 模式，而且 Supabase 会限制对 auth 模式的访问，以防止一些意外的自定义更改破坏 Auth 服务的功能。

🌐 Supabase Auth uses your project's database to store user data. It relies on the auth schema, and Supabase restricts access to the auth schema to prevent unintended custom changes that could break the functionality of the Auth service.

检查 auth 架构在 仪表板触发器部分 是否包含任何触发器。

🌐 Check if the auth schema contains any triggers in the Dashboard's trigger section.

  1. 使用 仪表板的功能部分 中的 security invoker 来识别相关功能
  2. 通过使用下面显示的 CASCADE 修饰符删除它们的函数来移除所有触发器（这个命令仍然有效，因为 postgres 角色拥有该函数，而 CASCADE 子句会间接删除触发器）。
1
DROP FUNCTION <function name>() CASCADE;
2
3
-- If you'd prefer, you can drop the trigger alone with the following query:
4
-- DROP TRIGGER <trigger_name> on auth.<table_name>;
  1. 用 security definer 修饰符重新创建这些函数
  2. 重新创建触发器

使用安全定义者的示例函数和触发器 SQL 编辑器 包含一个 用户管理 的模板。在其中，有一个如何设置使用安全定义者的触发器的工作示例，可能值得参考：

1
create table profiles (
2
  id uuid references auth.users on delete cascade not null primary key,
3
  updated_at timestamp with time zone,
4
  username text unique,
5
  full_name text,
6
  avatar_url text,
7
  website text,
8
9
  constraint username_length check (char_length(username) >= 3)
10
);
11
12
create function public.handle_new_user()
13
returns trigger
14
set search_path = ''
15
as $$
16
begin
17
  insert into public.profiles (id, full_name, avatar_url)
18
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
19
  return new;
20
end;
21
$$ language plpgsql security definer;
22
23
create trigger on_auth_user_created
24
  after insert on auth.users
25
  for each row execute procedure public.handle_new_user();

解释 #

🌐 Explanation

在 Supabase 中最常见的设计模式之一是给 auth.users 表添加触发器。管理认证的数据库角色（supabase_auth_admin）只拥有执行其职责所需的必要权限。所以，当由 supabase_auth_admin 操作的触发器在认证模式外进行交互时，就会导致权限错误。

🌐 One of the most common design patterns in Supabase is to add a trigger to the auth.users table. The database role managing authentication (supabase_auth_admin) only has the necessary permissions it needs to perform its duties. So, when a trigger operated by the supabase_auth_admin interacts outside the auth schema, it causes a permission error.

安全定义者函数保留创建它的数据库用户的权限。只要它是 postgres 角色，你的认证触发器就应该能够与外部表进行交互。

🌐 A security definer function retains the privileges of the database user that created it. As long as it is the postgres role, your auth triggers should be able to engage with outside tables.