使用 Supabase Auth 和 Cloudflare 构建带身份验证的 Web 应用

大家好，我是 Liberogic 的 Matsun。
这是我第一次撰写文章。

从 PHP2Shell 到 HTTP2Shell，安全相关的新闻接连不断。
Cloudflare 也发布了针对 PHP 漏洞的 WAF 防护措施。
我开始觉得，今后不仅要关注 Web 系统，也需要更加重视员工的电脑和网络环境。

前不久，CTO大塚撰写了一篇关于使用Supabase和Cloudflare开发专用Web应用的文章。
本次作为其续篇，我将介绍业务应用中不可或缺的“认证”相关内容。

在内部系统和面向合作伙伴的门户网站中，仅仅能够登录是不够的。需要根据用户的不同，区分其可查看的信息和可使用的功能。为此，我们采用的是Supabase Auth。

业务应用通常都需要登录功能

• 内部申请与审批系统
• 会员专属主页
• 面向合作伙伴的门户
• 工时与考勤管理
• 项目管理
• 面向门店与网点的管理系统

这类 Web 应用，大多数情况下都需要登录功能。
但仅仅“输入 ID 和密码即可登录”是不够的。
例如，在内部申请系统中，

• 普通员工
• 上级主管
• 据点管理员
• 本部管理者
• 系统管理员

即使使用的是同一个应用，例如
面向合作伙伴的门户，如果A公司的负责人能看到B公司的信息，那就麻烦了。
在带认证的Web应用中，

• 确认“对方是谁”的身份认证
• 决定“此人可以做什么”的权限管理

需要分开考虑。

使用 Supabase Auth 统一管理登录部分

Supabase Auth 是 Supabase 提供的认证功能。例如，

• 邮箱地址 + 密码
• Magic Link
• 一次性密码（OTP）
• 使用 Google 等的社交登录

等方式。
业务应用通常首先采用邮箱地址加密码的方式，但根据用途不同，也可以采用 Magic Link 登录而无需设置密码。这类功能如果无需从零开始全部由自己实现和运维，是一个很大的优势。
从界面上看，认证只是一个登录表单，但其背后，

• 用户注册
• 密码管理
• 邮箱地址验证
• 登录状态管理
• 密码重置
• 会话管理

等大量处理。
这些认证相关的基础功能可以交由 Supabase 负责。

与 Cloudflare 组合使用的大致方式如下

在上一篇关于CTO的文章中，

Cloudflare负责入口，Supabase负责数据基础设施

这一思路我们已经讲过，即使加入认证功能，基本的设计理念依然相同。

ユーザー
  ↓
Cloudflare
  ↓
Next.js
  ↓
Supabase Auth
  ↓
Supabase
 ├ Database
 └ RLS

用户访问Web应用，并通过Supabase Auth登录。
系统会根据已通过认证的用户信息，在Next.js端切换显示的页面，或从Supabase获取所需的数据。
Cloudflare仍然作为Web应用的入口使用。实际上，这里还会根据需要加入

• Cloudflare Workers
• R2
• SendGrid
• Box
• 外部API

等服务。
无需把所有功能都放在Supabase中实现，也无需全部依赖Cloudflare。
各自发挥所长即可。

根据登录用户切换页面内容

例如，假设我们要开发一个面向合作伙伴的门户网站。用户登录后，

○○株式会社
森本様

現在の案件
資料一覧
お問い合わせ
アカウント設定

会显示如下页面。
其他公司的用户登录时，只显示该公司的项目和资料。
管理员登录时，则会显示

• 全部合作伙伴
• 全部案件
• 用户管理
• 文件管理
• 操作历史

等，显示管理员专用菜单。
只看界面的话很简单，但在背后，

需要判断当前登录的是哪位用户

，并获取与该用户关联的信息。
使用 Supabase Auth 时，已认证的用户会拥有用于识别身份的 ID，因此我们会将其与业务数据关联起来。

不只在浏览器中进行认证

使用 Next.js 等开发 Web 应用时，认证信息不一定只在浏览器端处理。服务器端也常常需要确认“此用户是否已登录”。
Supabase 为 SSR 环境提供了基于 Cookie 的认证方式，在 Next.js 中可以同时在客户端和服务器端处理用户会话，这一机制非常重要。例如，

/login

任何人都可以查看，但

/dashboard

仅限已登录用户可访问，

/admin

仅限管理员可访问，按 URL 粒度进行访问控制。
仅在页面上隐藏“管理”按钮并不能保障安全。
即使有人直接打开 URL 或直接调用 API，也需要在服务器端和数据库端进行验证，确保没有问题。

认证与权限管理是两回事

在设计业务应用时，认证与权限管理需要分开考虑。
使用 Supabase Auth 时，

“森本先生已登录”

这一点可以确认。但是，

“森本先生应该能看到哪些数据”

则是另一个问题。例如，

ユーザー
 ↓
所属会社
 ↓
所属拠点
 ↓
役割
 ↓
閲覧できるデータ

这样的关系需要进行设计。
在业务应用中，这一部分因应用而异，差别很大。
如果只有“管理员”和“普通用户”两种角色，还比较简单，但是，

• 总部
• 分支机构
• 门店
• 合作伙伴
• 代理商
• 外部工作人员

一旦加入外部工作人员等角色，权限设计会迅速变得复杂。
而在使用 Supabase 时，权限控制中的关键是**RLS（Row Level Security，行级安全）**。
使用 RLS 后，无论是在数据库层面，

• 仅限自己的数据
• 仅限同一公司的数据
• 仅限同一据点的数据
• 管理员可访问全部

等控制。
RLS 的具体设计将在下一篇文章中介绍。

在 Cloudflare 侧同样加以防护

虽然有 Supabase Auth，但并不意味着 Web 应用的安全性完全交由 Supabase 负责。在 Cloudflare 侧，

• WAF
• DNS
• HTTPS
• Bot 防护
• 速率限制
• 通过 Workers 处理 API
• 根据需要结合 Cloudflare Access

等方案。也就是说，

Cloudflare
   ↓
Webアプリ
   ↓
Supabase Auth
   ↓
権限制御
   ↓
Database

因此需要分层进行考虑。
“有登录页面所以就安全”并不成立。
在 Web 应用中，需要分别在入口、应用程序、API 和数据库各层进行适当的控制。

例如，可用于以下这类应用

Supabase Auth与Cloudflare的组合可用于各类业务应用。

内部申请与审批应用

• 员工登录后提交申请，由上级及管理员进行审批
• 普通员工仅可查看自己的申请
• 上级可查看本部门的申请
• 管理员可查看全部申请

等权限控制。

面向合作伙伴的门户

按合作伙伴分别发放账户，

• 项目信息
• 资料
• 文件
• 公告
• 咨询记录

等内容。
虽然是同一个 Web 应用，但根据登录的公司不同，显示的内容也会有所变化。

会员专属主页

仅会员本人可以查看

• 注册信息
• 申请记录
• 合同信息
• 文件
• 各项设置

等信息。

据点管理系统

全国各地门店和营业所的负责人登录后，可以登记自己所在据点的信息。
总部可以统一查看所有据点的信息。
此类用途也可以结合 Supabase Auth 与权限控制进行使用。

不再需要从零搭建认证基础设施

过去，如果要开发带认证功能的业务系统，首先需要设计认证服务器如何搭建、会话如何管理、以及如何与数据库关联等问题。
当然，即使是现在，设计本身仍然是必要的。
不过，借助 Supabase Auth 这类机制，可以减少从零构建认证基础设施的工作量。把节省下来的时间，

• 向谁展示什么内容
• 允许谁执行哪些操作
• 业务上需要哪些权限

投入到真正应该思考的问题上。
就我个人而言，这正是在业务应用中使用 Supabase 的一大优势。

总结

借助 Supabase Auth 与 Cloudflare 的组合，即使架构相对简单，也能开发出带认证功能的 Web 应用。
但关键并不在于制作登录页面。
对于已通过认证的用户，

• 展示什么内容
• 允许执行什么操作
• 可以访问哪些数据

还需要进行设计，才能成为可在实际业务中使用的 Web 应用。
Supabase Auth 负责确认“用户是谁”，之后的权限控制则在应用和数据库侧进行搭建，大致是这样的思路。

下一次将介绍如何在业务应用中使用 Supabase 的 RLS。