- 1. プライバシーロールとは
- 2. プライバシーロールの設定方法
- 3. プライバシーロールの動作確認をしてみよう
- 4. プライバシールールのデバッグ
- 5. プライバシーロールの設定サンプル（2020/07/21追記）
- 6. ファイルの取り扱いについて（2020/07/21追記）
- まとめ
今回は、Bubble でアプリを作成する場合に、非常に重要なプライバシーロールについて、ご紹介したいと思います！データにロールを定義することで、データアクセスへの権限を付与することができるため、セキュリティを向上させることが可能です。Bubble でアプリを作成する場合は、是非参考にしてみてくださいね。
1. プライバシーロールとは
実はBubbleでは、プライバシーロールを設定するまで、基本的に作成されたデータは誰でも参照することができてしまいます。これは、ブログのコメントなど誰にでも閲覧させたいような項目には適していますが、メールアドレスや個人的なメッセージなど共有したくないデータには不適切です。
例えば、プライバシーロールを設定せずに、RepeatingGroupにDBからデータをバインドする場合、以下の図のように「Do a search for」の条件で表示するデータを絞り込むことはできますが、これは単に絞り込みを行っているだけとなります。つまり、データ表示がされていないだけで、実際にデータへのアクセスは出来てしまう状態です。
ここで、データにアクセスできるかどうかの権限を付与するために定義するのがプライバシーロールです。プライバシーロールを定義するとサーバーに適用され、「Do a search for」で条件を指定しなくても、ロールの条件を満たす場合のみデータを表示されることが保証されます。
プライバシーロールを意識しなくてもアプリ開発は出来てしまいますし、条件などを適用して画面上にデータを表示させていないと、見落としてしまう設定かもしれませんが、セキュリティを考える上でプライバシーロールは非常に重要な項目です。しっかり設定するようにしましょう。
では、次項で早速、プライバシーロールの具体的な設定方法をご紹介します！
2. プライバシーロールの設定方法
2-1. Privacyタブ
プライバシーロールの設定は、Dataタブ内にある「Privacy」から行います。ロールはデータタイプ（DBテーブル）に対して定義していきます。
2-2. ロールを定義する
「Privacy」の「Custom data types」でロールを追加するデータタイプを選択し、「Define a new role」をクリックしてロール名を入力します。ここではサンプルとして「Message」テーブルを選択しロール名は「送信者/宛先」と入力しました。
「When」に特定のユーザーがロールの一部であるかどうかをチェックする条件を定義します。ここでは、「Current User is This Message's Destinee or Current User is This Message's Creator 」と入力していますが、これは「現在のユーザーが、MessageテーブルのDestineeフィールド、またはCreatorフィールドのユーザーである時」に「Users who match this rule can...」で指定していることができるという意味になります。
以下が、ロールのユーザーがデータに対してできることです。
| できること | 説明 |
|---|---|
| View all fields | テーブルのすべてのフィールドを表示できるようになります。このチェックボックスをオフにすると、このロールのユーザーが表示できるフィールドを個別に選択できます。 |
| Find this in searches | 検索結果に含めないようにするには、このチェックボックスをオフにします。例えば、オンにした状態でRepeatingGroupにデータをバインドさせた場合、ロールに含まれないデータは空行として表示されることになります。検索結果にロールに含まれない行を表示したくない場合はチェックをオフにしましょう。 |
| View attached files | このチェックボックスがオフの場合は、ユーザーはこのテーブルにアップロードされたファイルを見ることができません。 |
| Allow auto-binding | ユーザーが入力内容を変更時点で、データを自動的に更新することができます。このチェックボックスをオンにすると、このロールのユーザーが自動更新できるフィールドを個別に選択できます。 |
Everyone else(default permissions) に表示されている定義が、ロールに含まれないユーザーに対して出来ることを定義します。Everyone else(default permissions) は、「Define a new role」でロールを作成すると自動で追加されます。以下の設定は、ロールに含まれないユーザーには、データアクセスに対する権限は何も付与しないという意味になります。
Allow auto-binding 補足
一般的に Allow auto-binding を利用する場合、Inputエレメントなどの「Enable auto-binding on parent element's thing」にチェックを入れることで適用しますが、もしプライバシーロールの定義がない場合は、以下の図ように「～ but there are no privacy rules ～」といったメッセージが表示されます。
プライバシーロールで定義を追加すると、変更時にフィールドの自動更新が可能になります。
3. プライバシーロールの動作確認をしてみよう
では、実際にプライバシーロールを設定した場合としない場合を比較して、動作を確認してみます。今回はサンプルとして、メッセージの送信者と受信者のみがそのデータを見ることができる簡単なページを作成していきます。
3-1. サンプルページの準備
では、まず画面から作成していきましょう。
メッセージの登録フォームには、自分の名前と送信先、メッセージタイトル、本文のInputエレメントを配置し、「メッセージを送信」ボタンでデータを登録します。
フォームから登録されたデータを表示するRepeatingGroupには、受信か送信かを示すアイコン、メッセージのタイトル、そのメールの送信者を表示します。
3-2. 「Message」テーブルの準備
「Message」テーブルには、以下のフィールドを作成します。
| フィールド名 | 詳細 |
|---|---|
| Content | メッセージ本文 |
| Destinee | 宛先（受信者） |
| Title | メッセージタイトル |
| Creator | 作成者（送信者） |
3-3. サンプルデータの登録
「User」テーブルに以下3名のデータを登録します。
- テストユーザー1
- テストユーザー2
- テストユーザー3
メッセージ登録フォームを利用して「Message」テーブルに以下のデータを登録します。
- テストユーザー1が、テストユーザー2とテストユーザー3にメールを送信しておく。
- テストユーザー2が、テストユーザー1にメールを送信しておく。
- テストユーザー3が、テストユーザー1とテストユーザー2にメールを送信しておく。
3-4. プライバシーロールを設定していない場合
では、準備したページでプライバシーロールを設定していない場合の動作を確認してみましょう。 CurrentUser をテストユーザー1にしてデータを表示します。
プライバシーロールを設定していないので、CurrentUser のテストユーザー1には関係ないデータが表示されています。
3-5. プライバシーロールを設定している場合
では、次に「Message」テーブルに「送信者/宛先」という名前の、条件を「Current User is This Message's Destinee or Current User is This Message's Creator 」としたロールを追加して表示してみます。
プライバシーロールの設定で、CurrentUser が送信者でも受信者でもない場合のデータが含まれない状態になりました。
4. プライバシールールのデバッグ
4-1. デバッグ時のユーザーを指定する方法
プライバシーロールの確認に限らずですが、デバッグする際にCurrentUserを指定したい場合は、「App data」タブでUserテーブルに表示されている「Run as →」をクリックすれば、ユーザーを指定して選択している Page の Preview を実行することができます。ユーザーを都度切り替えてデバッグしたい場合は、「Run as →」を利用しましょう。
4-2. データ比較について補足
プライバシーロールのデバック時は、特定のフィールドを非表示にするため、デバッグが複雑になる可能性があります。そのため、Bubble のマニュアルを参照すると、プライバシーロールによって表示される値が異なる場合は、デバック時にメンションが表示されると表記されていますが、現在は非表示フィールドをデバッカーで確認すると、値が「empty」 として表示されているようです。
5. プライバシーロールの設定サンプル（2020/07/21追記）
前項ではサンプルとして、メッセージの送受信について取り上げましたが、ここでは補足として、よくあるプライバシーロールの設定をご紹介したいと思います。
なお、本項でのサンプルでは、ノーコードラボが Bubble で公開しているテンプレート「StarterKit for Japan」を使用して簡単に説明します。StarterKit for Japan テンプレートについての詳しい説明は以下の記事で解説していますので、ご参考くださいね。
5-1. サンプル①
サンプルの1つ目は「登録されたユーザー情報についてアクセスできるのは、登録した人自身と管理者だけ」といった場合の設定です。ここでは、直接 User Type にプライバシーロールを定義しています。
User Type に「user permission」という名前で、「This User is Current User or Current User's User Rank is 管理者」の時（User Type の参照するデータが 現在のユーザーである、または現在のユーザーが管理者の場合）にロールに含めるといった定義しています。
また、その際のデータに対する権限は、すべてのフィールドデータの表示（View all fields）、検索（Find this in searches）、登録されているファイルの表示（View attached files）についての権限を持つこととしています。
Everyone else (default permissions) は何もチェックしていないので、ロールに含まれない場合は、データの表示も検索もできない設定になっています。例えば、もしここで表示させないデータをメールアドレスに限りたい場合は、email 以外のフィールドをチェックすることで、その他は表示させるといったことも可能です。
なお、ここで使用している「User Rank is 管理者」という設定は、User Rank という Option sets を定義して、User Type にこの User Rank を型とした「User Rank」フィールドを作成しているため、「Current User's User Rank is 管理者」という表現になっています。
5-2. サンプル②
2つ目のサンプルは「アプリに登録済みのユーザーに対してのみデータを表示する」といった場合です。ここではコメントを閲覧できるのはアプリ会員だけといったような意味合いになりますが、その他アプリで会員向けのお知らせといった場合などに使える設定だと思います。
ここでは、Comment Type というテーブルに「comment permission」という名前で、「Current User is logged in」という条件を使って「現在のユーザーがログインしている場合」とすることで、つまりはアプリの登録ユーザーとして Comment データにアクセスできるようにしています。
6. ファイルの取り扱いについて（2020/07/21追記）
次に Bubble でファイルをアップロードした場合の取り扱いについて補足しておきたいと思います。 見落としがちですが、Bubble のデフォルトでは、アップロードされたファイルは、ファイルへのリンクを知っているすべてのユーザーが表示することが可能です。その為、もしアップロードしたファイルをプライベートにしたいといった場合には、別途設定する必要がありますので、注意が必要です。
具体的には、アップロードするファイルが画像でプライベートにしたい場合、PictureUploader エレメントのプロパティで設定していきます。 Make this file private をチェックオンし、Attach this file to を Current User などにして、ファイルを表示するためのアクセス権を持つユーザーを決定します。ここでは、StarterKit for Japan テンプレートの ユーザーアイコンの画像をプライベートに設定しています。
上記の設定を行うと、File manager でアップロードしたファイルを見てみると「Attached to」に User Type の Unique id が指定されていることが確認できます。
この設定を行った上で、前項のサンプル①にあるプライバシーロールの設定を行った場合、ユーザーについての情報やアイコンを見ることができるのは、ユーザー自身と管理者だけということになります。
なお、アプリを開発、検証していると、権限を持たないファイルが表示される場合があり「プライバシーロールが有効にならない？」と混乱することがあるかもしれません。 そういった場合は、Cookie が影響している可能性がありますので、作成している Bubble アプリに関する Cookie を削除することをお勧めします。
以下は Chrome で Cookie を削除する場合の手順です。
開発ツールを立ち上げて、Application の Cookies から、作成している Bubble アプリのドメインに関係する Cookie を削除します。
また、検証する際、前項の「デバッグ時のユーザーを指定する方法」でご紹介した「Run as →」を使用した起動方法の場合は、File manager の「Attached to」に登録されるユーザーは 使用中のユーザーの Unique id ではなく「admin_user_～」といった特別なユーザーが使用されるようです。ファイルのアクセス権限を含めた検証を行う場合は、パスワードを使用したサインインフローで確認するようにしましょう。
まとめ
いかかがでしたか？今回は、Bubble でアプリを作成する場合に、非常に重要なプライバシーロールについてご紹介しました。セキュリティアップに是非参考にしてみてくださいね。では、次回もどうぞお楽しみに！
