【Bubble 入門 #10】Current User で実現！プライバシーに配慮した安全なアプリの実装方法
ブンブンハロー！
帰宅時に5駅分歩くことで健康になろうとしている男、上松です。
さて今日もやっていきましょう、Bubble 入門シリーズの第10回🎉
Current User を使いこなして、ユーザーに個別化された表示を実現しよう編！
前回の記事では、Bubble でログイン機能を実装する方法をご紹介しました。
簡単な手順でサインアップ、ログイン、ログアウトの機能を実装できることを体験していただけたのではないでしょうか。
👉 【Bubble 入門 #9】簡単・安全・快適！Bubble でログイン機能を実装しよう
しかし、ログイン機能を実装しただけでは、まだ十分とは言えません。
現状では、他人が投稿した To Do を見ることができてしまいます。これはプライバシーの観点から問題があります。
個人利用が目的の To Do アプリで「同僚の○○○さんの私的な To Do が見えちゃう」なんてことになったら大変ですよね。
そこで今回は、Current User の概念を学び、プライバシーに配慮した表示を実現する方法をご紹介します。
これにより、各ユーザーが自分の To Do だけを見ることができるようになります。
一緒に学んでいきましょう！
目次
- Current User とは？
- Current User を取得する
- Current User に紐づくデータのみを取得する
- Privacy rules の設定
- まとめ
1. Current User とは？
Current User とは、「現在ログインしているユーザー」のことを指します。
Bubble では、ユーザーがログインすると、そのユーザーの情報が Current User として自動的に登録されます。
Current User を利用することで、ログインしているユーザーの情報を簡単に取得したり、そのユーザーに関連するデータだけを表示したりすることができます。
これは、パーソナライズされたユーザー体験を提供する上で非常に重要な概念です。
例えば、「ようこそ、ユーザー名さん！」というメッセージを表示したり、ユーザーが作成した To Do だけを表示したりする際に、Current User の情報を活用します。
2. Current User を取得する
2-1. Insert dynamic data で Current User を使用
まずは、Current User の情報を画面に表示してみましょう。
具体的には、index ページで “Your To Do” と書いてあったところに、よりパーソナライズされた ”ユーザー名 ’s To Do”という表記に改めてみます。
Current User は “Insert dynamic data” で簡単に参照できます。
今回はユーザー名を表示したいので ”Current User's name ’s To Do” とします。
以上で、Current User の情報を取得する設定は完了です！
2-2. Run as で確認
設定ができたら、Run as 機能を使って動作確認をしてみましょう。
Run as は、特定のユーザーでログインしたことにする開発者用プレビュー機能です。これにより、異なるユーザーでログインしたときの動作を簡単にテストできます。
わざわざログインフォームに email と password を入力してユーザーを切り替える必要がないのが嬉しいですね！
Run as の実行手順：
- “Data" タブを開きます。
- "Data" タブ内の "App data" サブタブを選択します。
- 左側のメニューから "All Users" を選択します。
- テストしたいユーザーを見つけ、そのユーザーの行にある "Run as" ボタンをクリックします。
まずは「東北ずん子」で Run as を実行してみます。
”Current User's name ’s To Do” が “東北ずん子’s To Do” になりました！
これはすなわち Current User が「東北ずん子」である（=「東北ずん子」でログインしている）状態でアプリをプレビューしていることを意味します。
続いて「ずんだもん」で Run as を実行してみます。
今度は ”Current User's name ’s To Do” が “ずんだもん’s To Do” になりました！
無事に Current User を「ずんだもん」に切り替えた状態でプレビューできています。
これで、Current User の基本的な使い方がわかりましたね。
3. Current User に紐づくデータのみを表示する
次に、Current User の To Do だけを表示するようにしましょう。
「東北ずん子」でログインしているのに「ずんだもん」の To Do が表示されてしまっている問題を解決します。
3-1. Repeating Group の Search for で Constraint を設定する
まず、重要な概念をリマインドしましょう。
Group は「Data type の箱（Thing の入れもの）」としての役割を持っています。
この考え方は、Repeating Group でも同様に適用されます。
復習: 「Data type の箱 (Thing の入れもの)」としての Group の役割
この概念を踏まえた上で、Repeating Group に Current User の To Do だけを表示するよう Constraint (= 縛り・制約) を設定していきましょう。
indexページの Repeating Group を選択- プロパティエディタの "Data source" で "Search for To Dos" をクリックし、詳細設定を表示
- “Add a new constraint” とクリック
Created By = Current Userを設定
この設定により、Repeating Group という「箱」には、Current User が作成した To Do の Thing だけが入るようになります。
つまり、この Repeating Group は Current User の To Do のみを表示するようになります。
3-2. Run as で確認
再び Run as 機能を使って、異なるユーザーでログインしたときに、それぞれのユーザーの To Do だけが表示されることを確認しましょう。
まずは Run as「東北ずん子」発動！
これで「東北ずん子」でログインしたときは「東北ずん子」の To Do だけが表示されるようになりました！
続いて Run as「ずんだもん」！Go！
「ずんだもん」でログインしたときは「東北ずん子」の To Do は表示されていません。OK！
4. Privacy rules の設定
ここまでの設定で、画面上では各ユーザーが自分の To Do だけを見ることができるようになりました。非常に簡単でした！
しかし、データベースレベルではまだ全ての To Do が全てのユーザーからアクセス可能な状態です。
これは潜在的なセキュリティリスクとなります。
そこで、Privacy rules を設定して、データベースレベルでのアクセス制御を行いましょう。
4-1. Privacy rules とは
Privacy rules は、Bubble におけるデータアクセス制御の中核機能です。
これにより、データの閲覧、編集、削除などの権限を細かく設定することができます。
具体的には以下のような制御が可能です：
- 特定のユーザーだけがデータを見られるようにする
- データの作成者のみが編集・削除できるようにする
- 特定の条件を満たすユーザーだけにアクセスを許可する
Privacy rules は Data type ごとに設定でき、アプリケーション全体のセキュリティを強化する上で重要な役割を果たします。
4-2. デフォルトは Publicly visible で危険
Bubble では、新しく Data type を作成すると、デフォルトで "Publicly visible" に設定されています。
確かに、私たちが自前で作成した To Do という Data type では、Privacy rules が “Publicly visible” となっています。
“Publicly visible” は日本語で「公に見えている」ですが、具体的に下記のような状態のことを指します：
- 全てのユーザー（ログインしていないユーザーも含む）が任意のデータを閲覧可能
- 全てのユーザーが任意のデータを作成、編集、削除可能
この設定は、セキュリティ上大きなリスクを伴います：
- データの不正アクセス：誰でも全てのデータにアクセスできてしまう
- データの改ざん：悪意のあるユーザーが簡単にデータを変更できてしまう
- プライバシーの侵害：個人情報が公開されてしまう可能性がある
開発時であっても、この "Publicly visible" の設定をそのまま使用することは推奨されません。
代わりに、開発の初期段階から適切な Privacy rules を設定する習慣をつけることが重要です。
To Do アプリのような個人情報を扱うアプリケーションでは、特に注意が必要です。
開発初期から適切な Privacy rules を設定し、セキュアなアプリケーション開発を心がけましょう。
4-3. 自分が作成した To Do のみにアクセスできるようにする
Data type To Do の Privacy rules を設定して、作成者（Creator）のみがアクセスできるようにしましょう。
- "Data" タブを開き、
To Doの Data type を選択 - "Privacy" タブをクリック
- “Define a new rule” で
User's own dataという名前の Privacy rules を作成 - "When” の条件を
This To Do's Creator is Current Userに設定 - “Users who match this rule can…” で以下の項目にチェックを入れる
- “View all fields” (全ての Field にアクセス可能)
- “Find this in searches” (検索によってアクセス可能)
- “View attached files” (紐付けられたファイルにアクセス可能)
- “Everyone else (default permissions)” で全ての項目のチェックを外す
これで、各ユーザーは自分が作成した To Do だけを見たり編集したりできるようになりました。
他のユーザーの To Do にはアクセスできなくなり、データベースレベルでのセキュリティが確保されています。
4-4. Run as で確認
Privacy rules の効果を Run as で確認しておきましょう！
そのためには、前節『3-1. Repeating Group の Search for で Constraint を設定する』で課した Created By = Current User という Constraint を一時的に外します。
この状態で Run as 「東北ずん子」すると…
このように「東北ずん子」の To Do のみが表示されました。
Created By = Current User という Constraint がなくても、Privacy rules レベルできちんと表示すべきでない To Do が弾かれているのです。
Privacy rules を予め設定しておくことの重要性がここに表れています。
例えば、以下のような状況を想像してみてください：
- 開発者が誤って Constraint を削除してしまった場合
- 慌ただしく新機能を開発している間に、データ取得のロジックにバグが混入していた場合
このような予期せぬ事態が発生しても、Privacy rules が適切に設定されていれば、データベースレベルで漏洩を防ぐことができます。
つまり、ロジックの実装に問題があったとしても、最後の砦として機能するのです。
しかし、Privacy rules が設定されているからといって、Created By = Current User の Constraint を外すべきではありません。
両者には異なる重要な役割があります：
- Privacy rules (@データベース層) は、アプリケーション全体のセキュリティを担保する「守り」の役割。
- Constraint (@アプリケーション層) は、クエリごとに柔軟に調整し得るもの。そして、フィルタリングの意図を明確にする「攻め」の役割。
このように Privacy rules と Constraint で二重の防御策を講じておくことで、より堅牢なセキュリティを実現できます。
特に、変更の対象となりやすい Constraint に万が一不備が生じてしまった時のために、Privacy rules は最初から適切に設定しておくことが重要です。
5. まとめ
Current User、そして Privacy rules を使用することで、ユーザーごとのアクセス制御を簡単に実現できることがお分かりいただけたと思います。
今回学んだポイントを振り返ってみましょう：
- Current User は「現在ログインしているユーザー」を指し、パーソナライズされたユーザー体験を提供する上で重要な概念です。
- Insert dynamic data で Current User の情報を簡単に表示できます。
- Repeating Group の Data source に Constraint を追加することで、Current User に関連するデータだけを表示できます。
- Run as 機能を使うと、異なるユーザーでの動作を簡単にテストできます。
- Privacy rules を適切に設定することで、データベースレベルでのセキュリティを確保できます。
これらの機能を活用することで、ユーザーごとに適切なデータを表示し、プライバシーに配慮したセキュアなアプリケーションを構築することができます。
さて、ここで Bubble 入門シリーズは（暫定的に）最終回を迎えました。
10回にわたるシリーズを通じて、Bubble の基本的な機能や概念について学んでいただきました。
いかがでしたか？もうなんでも実装できてしまいそうな気がしてきませんか…！？
私たち株式会社Biz Freakは、Bubbleの力を最大限に活用して、通常比3倍速で新規事業のプロダクト開発を行っています。「爆速開発」で MVP を構築し、「爆速改修」で早期の PMF を目指します。
もしあなたがこの入門シリーズを通じて Bubble に興味を持ち、ローコード開発の可能性に魅力を感じたのであれば、ぜひ私たちのチームに参加してください。
あなたの開発力を新規事業に活かさないのは「宝の持ち腐れ」、非常に勿体無いと思います！
新しい技術で事業の成長に直接貢献したい方、従来の開発手法の枠を超えた挑戦をしたい方、そして何より、テクノロジーを通じて世の中に価値を生み出したい方を、私たちは歓迎します。
👉 https://bizfreak.co.jp/recruit
＼ 人生は、Current User や！／
では、またの機会にﾉｼ
