Skip to content
Home

生产清单

在开发完你的项目并决定它可以投入生产后，你应该通过这个清单来确保你的项目：

🌐 After developing your project and deciding it's production ready, you should run through this checklist to ensure that your project:

安全 #

🌐 Security

  • 确保你在 Supabase 仪表板的 数据库 > 表 部分的所有表上都启用了行级安全（RLS）。
    • 没有启用 RLS 且没有合理策略的表允许任何客户端访问和修改它们的数据。通常这不是你想要的。
    • 了解更多关于RLS的信息。
  • 通过启用行级安全（RLS）并设置行安全策略，在包含敏感数据的表上启用复制：
  • 在仪表板的 数据库 > 设置 > SSL 配置 部分开启 SSL 强制。
  • 从仪表板的 数据库 > 设置 > 网络限制 部分，为数据库启用 网络限制。
  • 确保你用多因素认证（MFA）来保护你的 Supabase 账户。
    • 如果使用 GitHub 登录，在 GitHub 上启用两步验证。
    • 既然你的 GitHub 账号赋予了你对 Supabase 组织的管理权限，你应该使用强密码和 U2F 密钥或 TOTP 应用的双重认证来保护它。
    • 如果使用邮箱+密码登录，请为你的 Supabase 账户设置 多因素认证 (MFA)。
  • 考虑在你的组织中启用 多因素身份验证 (MFA) 强制。这样可以确保所有用户在使用组织和项目资源时都必须拥有有效的 MFA 支持的会话。
  • 考虑在 Supabase 仪表板的 组织 > 团队 部分为你的 Supabase 组织添加多个所有者。这样，即使其中一个所有者联系不上或失去账户访问权限，你仍然可以拥有组织的所有者权限。
  • 在仪表板的 身份验证 > 提供商 部分启用电子邮件确认。
  • 在仪表板的 认证 > 提供商 部分，为一次性密码（OTP）设置一个你觉得合适的有效期。
    • 我们建议将此设置为3600秒（1小时）或更短。
    • 如果你需要更高的熵，就增加一次性密码的长度。
  • 如果你的应用需要更高的安全性，可以考虑为你的用户设置多因素认证（MFA）。
  • 使用自定义 SMTP 服务器发送认证邮件，这样你的用户就可以看到邮件来自一个可信的域（最好是与你的应用托管在同一个域名下）。可以从任何主要的邮件提供商获取 SMTP 凭证，比如 SendGrid、AWS SES 等。
  • 考虑一下你作为攻击者可能会如何滥用你的服务，然后采取措施来减轻这种情况。
  • 查看这些常见的网络安全威胁。

表现 #

🌐 Performance

  • 确保你有合适的索引来应对常见的查询模式
  • 进行负载测试（最好在预发布环境上）
    • 像 k6 这样的工具可以模拟来自许多不同用户的流量。
  • 如果你需要更多资源，请升级你的数据库。如果你需要超出计算和磁盘表中列出的内容，请联系enterprise@supabase.io。
  • 如果你预计流量会激增（例如大型上线）并且使用的是团队或企业计划，联系支持 提供关于你上线的更多详情，我们会帮你关注项目情况。
  • 如果你预计你的数据库大小会超过 4 GB，请在仪表板的 设置 > 插件 部分启用及时恢复（PITR）插件。

可用性 #

🌐 Availability

  • 使用你自己的 SMTP 凭据，这样你就可以完全控制你在仪表板的 身份验证 > 邮件 > SMTP 设置 部分发送的事务性认证邮件的送达情况。
    • 你可以从任何主要的邮件服务提供商获取 SMTP 凭证，比如 SendGrid、AWS SES 等。查看我们的 SMTP 指南 获取更多设置细节。
    • 使用自定义 SMTP 提供商时，身份验证邮件的默认速率限制是每小时 30 个新用户。如果你要进行重大公开公告，可能需要超过这个数量。
  • 我们可能会暂停在7天内活跃度低的免费计划应用，以节省服务器资源。
    • 你可以从 Supabase 控制面板 恢复已暂停的项目。
    • 升级到专业版，以确保我们不会因为不活跃而暂停你的项目。
  • 免费的计划项目无法下载数据库备份。
    • 查看 数据库备份指南 以了解更多选项和保留详情。
    • 如果你需要更低的恢复点目标（RPO），可以启用时间点恢复（PITR）。PITR 允许你以更短的间隔备份项目。这让用户可以选择任意时间点恢复，精确到秒。
  • Supabase 项目默认使用的磁盘提供 99.8% 到 99.9% 的耐久性。
    • 如果你需要在磁盘故障事件中保持可用性，可以使用 只读副本
    • 如果你需要应对磁盘故障事件的耐久性，就使用 PITR
  • 升级到 Supabase 专业版计划可以让你访问我们的支持团队。

部署 #

🌐 Deployment

  • 连接你的 GitHub 仓库，并在集成设置中启用 部署到生产，以从你的 main 分支自动部署（设置集成）
    • 这可以确保模式更改一致部署，避免在本地机器上手动执行 supabase db push
  • 如果你使用的是专业版计划，可以考虑启用分支，在迁移进入生产环境之前先在预览环境中进行测试

速率限制、资源分配和防滥用 #

🌐 Rate limiting, resource allocation, & abuse prevention

  • Supabase 采用多种保护措施应对突发的流量，以防止滥用并帮助最大化平台的稳定性
    • 如果你使用的是团队或企业计划，并且预计会有高负载事件，比如生产发布、重负载测试或长期高资源使用，请通过 支持表单 提交工单寻求帮助。请至少提前 2 周通知。

认证速率限制 #

🌐 Auth rate limits

  • 下表显示了以下身份验证端点的速率限制配额。你可以在仪表板的 身份验证 > 速率限制 部分为你的项目配置身份验证速率限制。
接口端点路径限制条件速率限制
所有发送邮件的端点/auth/v1/signup /auth/v1/recover /auth/v1/user[^1]请求总和截至 2024 年 9 月 3 日，这已更新为 2 封邮件每小时。你只能通过自己的自定义 SMTP 设置来更改这个。
所有发送一次性密码（OTP）的端点/auth/v1/otp请求总和默认每小时 360 个 OTP。可自定义。
发送一次性密码或魔法链接/auth/v1/otp上次请求默认在允许新请求前有 60 秒的时间窗口，可自定义。
注册确认请求/auth/v1/signup上次请求默认情况下，新的请求允许前的时间窗口为 60 秒。可自定义。
密码重置请求/auth/v1/recover上一次请求默认在允许新请求前有 60 秒的窗口，可自定义。
验证请求/auth/v1/verifyIP 地址每小时360次请求（突发高达30次请求）
令牌刷新请求/auth/v1/tokenIP 地址每小时 1800 次请求（突发可达 30 次请求）
创建或验证多因素认证挑战/auth/v1/factors/:id/challenge /auth/v1/factors/:id/verifyIP 地址每分钟 15 次请求（突发可达 30 次请求）
匿名登录/auth/v1/signup[^2]IP 地址每小时 30 次请求（突发可达 30 次）

实时限制 #

🌐 Realtime limits

防止虐待 #

🌐 Abuse prevention

  • Supabase 在注册、登录和重置密码的端点上提供 CAPTCHA 保护。阅读 Auth CAPTCHA 指南 了解更多关于如何使用这种方法防止滥用的细节。

🌐 Email link validity

  • 在处理企业系统时，电子邮件扫描器可能会扫描你的邮件，并对重置密码链接或注册链接发起 GET 请求。由于 Supabase Auth 中的链接是一次性使用的，用户在扫描后再打开邮件点击链接时会收到错误。为了解决这个问题，可以考虑修改邮件模板，将原始魔法链接替换为你自己控制的域名链接。该域名可以向用户显示一个“登录”按钮，点击后会将用户重定向到原始的魔法链接 URL。
  • 在使用自定义 SMTP 服务时，有些服务可能会启用链接跟踪，这可能会覆盖或破坏 Supabase Auth 发送的电子邮件确认链接。为了防止这种情况发生，我们建议在使用自定义 SMTP 服务时关闭链接跟踪。