はじめに
ポートフォリオの Web アプリに、ゲストユーザー機能を実装しました。見てもらう人に、メール登録の前でも入りやすくしたかったからです。
テスト用アカウントを職務経歴書のどこに書くかは、別の記事にまとめています。
今回は、登録の前に見た目や設定、登録画面をその端末の中で試せるようにしています。データの保存、写真のアップロード、バーコード照合、AI アシストは、本登録のあとです。
公式の匿名ログインでは、仮の人にも自分のデータを残させて、あとからメールを足す使い方が先に挙がっています。このポートフォリオでは、サーバーに残す操作は本登録後にしました。
この記事では、その方針と、Supabase が求める is_anonymous の確認を書きます (｡･ω･｡)
想定読者
- Supabase で「ゲストではじめる」を足したい方
- 行のルールを「自分の ID だけ」にしたあと、ゲストの扱いを決めたい方
- 登録の前に、画面と設定だけ触ってもらいたい方
私の属性
- 個人開発のポートフォリオです
- 認証は Supabase Auth です。メール登録と、ゲスト開始を併用しています
ゲストに許したのは、端末の中だけ
登録の壁の前に、アプリの雰囲気を触れるようにしました。サーバーに残る操作は、本登録のあとです。
境界は、請求の有無だけではありません。端末の中で終わる操作はゲストのまま、サーバーに残す操作は本登録後です。
ゲストのままできることは、次です。
- 画面の見た目を確認する
- 設定を、その端末の中だけで変える
- 登録画面を進め、下書きを端末に残す
- 写真を、アップロードせずにプレビューする
本登録のあとになることは、次です。
- データをサーバーへ保存する
- 設定をアカウントへ保存する
- 写真をアップロードする
- バーコード照合や AI アシストなど、外部へ問い合わせる
- 集計のように、サーバー上のデータを読む
設定画面は開けます。アカウントへの保存は、本登録のあとです。
仮の人にも、部屋番号がある
Supabase の匿名ログインは、signInAnonymously() で仮の利用者を 1 人作ります。メールもパスワードもありません。それでもログイン済みです。
役割の名前は、本登録した人と同じ authenticated です。違いは、トークンについている「仮の人か」という印です。Supabase では is_anonymous です。
| 操作 | データベースから見た状態 |
|---|---|
| まだ何も押していない | 公開キーだけ。役割は anon
|
| ゲストではじめる | 仮の利用者ができる。役割は authenticated
|
| メールで本登録する | 同じ利用者のまま。印が外れて本登録になる |
マンションで言うと、こうです。
- まだ押していない人は、エントランスの外にいます
- 「ゲストではじめる」は、名前を書かずに仮の部屋番号をもらうことです。鍵は本物です
- 本登録は、その同じ部屋番号にメールを書くことです。部屋番号は変わりません
「この行は自分の ID だけ」というルールは、鍵の部屋番号と、荷物の部屋番号が一致するかを見ます。仮の入居者にも部屋番号があるので、この条件は通ります。
他人の行は、部屋番号が違うので対象外です。このルールが見ているのは、今のログイン ID と行の持ち主が一致するかです。本登録かどうかは見ていません。
匿名ログインと、公開キーの役割 anon は別です。ゲスト開始のあとは authenticated です。
公式の説明はこちらです。
止め方は、入口と部屋の両方
サーバーに残す操作は、2 か所で止めています。
- API の入口
- データベースの行ルール
入口では、トークンの is_anonymous を見ます。仮の人なら HTTP 403 を返し、メッセージは「本登録が必要です」にしています。画面側は、その応答を本登録への案内にします。
データベースでは、「自分の ID か」に加えて、「仮の人ではないか」も見ます。入口を通らない経路でも、ゲストの行操作は拒否します (=^･ω･^=)
公式ドキュメントにある形は、次のような restrictive です。表名は例で、このポートフォリオの表ではありません。
create policy "本登録した人だけ追加できる"
on items as restrictive for insert
to authenticated
with check (
(select (auth.jwt()->>'is_anonymous')::boolean) is false
);
restrictive は、同じ操作の他の許可ルールと AND になります。仮の人を止める条件は、こちらに置きます。許可ルールだけを足すと、条件は OR になり、仮の人が通ります。
公式の例では、閲覧は仮の人にも許し、追加だけを本登録者に限る、という分け方もあります。こちらはサーバーへ残す操作を、仮の人には許していません。
意識していること
新しい画面を足すとき、ゲストが触った結果を先に分けています。
機能を足すときの確認
- 端末の中だけで終わるなら、ゲストのままにする
- 保存、アップロード、外部への問い合わせは、本登録のあとにする
- API の入口と、データベースの行ルールの両方で、仮の人を止める
- ゲストには、生のエラーではなく本登録の案内を出す
まとめ
見てもらう人が登録前に入れるよう、匿名ログインのゲストを付けました。仮の利用者はログイン済みなので、サーバーに残す操作は「本登録か」で止めています (´▽｀)