この記事では、ノーコードツールBubbleのユーザータイプとOAuth(オーオース):X を用いたログインについて紹介します。中にはOAuth(オーオース)初めての人もいるかと思いますので、じっくりと記事をご覧ください。
それではまずBubbleのユーザータイプからご説明します。
ユーザータイプ
ユーザータイプとは
Bubbleは、アプリケーションがユーザー管理システムに依存していることを前提としています。したがって、新しいBubbleアプリケーションは、いくつかの追加のプロパティを持つ組み込みのユーザーデータタイプを持っています。
あなたのアプリケーションがユーザー(user)を使用しない場合、ユーザータイプの説明(この記事)はあなたのアプリケーションに影響を与えません。
ユーザータイプと他のタイプの違い
ユーザータイプは、アプリケーションで定義する他のデータタイプと非常に似た動作をします。例えば、ユーザーを変更したり、ユーザーを削除したり、繰り返しグループにリストアップしたりすることができます。
しかし、いくつかの重要な違いがあります。ユーザーは、アプリケーションでセッションや認証を処理するために使用することができます。
言い換えれば、ユーザータイプは、現在アプリケーションを使用している人を知るために使用することができるということです。
ユーザーは電子メールによって一意に定義されます。また、ユーザーが外部サービス(Facebook OAuthなど)を介して認証している場合はそのIDによって一意に定義されます。
したがって、ユーザーは「Create a new thing action」ではなく、「Sign the user up」や「Create an account for someone else」アクションで作成されます。
このようなアクションをワークフロー(実行モード)で実行すると、「User」タイプの新しいものが作成され、メールの一意性が検証されます。
ユーザーが「ユーザーのサインアップ」アクションを実行すると、ユーザーはパスワードを入力することができ、「他の誰かのためのアカウントを作成」を使用すると、ユーザーは「一時的なパスワード」としてマークされます。
また、「設定」タブで関連するパラメータを定義した場合、パスワードを変更するように促されます。
この設定により、まだ自分のパスワードを入力していないユーザーをリダイレクトするページを選択することができ、ユーザーが自分のパスワードを定義できるようなフォーム(関連するワークフロー)を作成することができます。
リダイレクトはページの読み込み時に発生し、「Log the user in」アクションの後では発生しません。
ユーザーデータタイプには、アプリケーションで使用できるいくつかの「組み込みフィールド」があります。最も重要で一般的なのはemailフィールドです。
これにはユーザーがサインアップした時に使用したemailが含まれており、ユーザーを認証するために外部サービスを使用している場合、外部サービスから取得できる最初のemailが含まれています。
2つ目のフィールドは「Eメール確認済み」で、ユーザーがEメールアカウントの所有権を確認するためのリンクをクリックしたかどうかを知るためのものです。このフィールドはyes/noの値で返答します。
一度delete thingアクションによってユーザーが削除されると、そのユーザーはデータベースに存在しなくなり、ログインなどができなくなることに注意してください。
現在のユーザーのコンセプト
あなたが使用できる最も重要なデータソースの一つは、「現在のユーザー」です。これは現在アプリケーションを使用しているユーザーデータベース内の別のユーザーと比較しています。
セッションとは、ある時間にアプリケーションを使用しているユーザーの概念を記述したものです。技術的には、セッションはブラウザレベルのクッキーによって定義されます。
アプリの設定によっては、これらのクッキーの有効期限を設定することができます。一般的に、このようなクッキーは無限であるため、ユーザーはログアウトするか、クッキーをクリアするまで同じセッションにいることになります。
状況に応じて、現在のユーザーは登録ユーザー、サインアップユーザー、一時的なユーザー(テンポラリーユーザー)のいずれかになります。
サインアップユーザー
ユーザーが(電子メールとパスワードで)Bbbleにサインアップした場合、この電子メールとパスワードを使用してデータベースに永続的なエントリーが作成されます。
ユーザーが新しいブラウザ(クッキーなし)でアプリを開き、ログインワークフローでその人に関する情報(メールやパスワード)を入力するとログインされます。また、現在のユーザーはログインしています」の値はyesとして返答されます。
現在のユーザーを変更した場合、これはデータベースオブジェクトに永続的に保存され、ユーザーが別のデバイスでアプリにログインした場合、そのユーザーのアカウントにも変更が適用されます
この重要な結果の一つは、データベース内の検索で見つけられるすべてのユーザーは、永久アカウントであるため、サーバー上で「ログインしている」とマークされるということです。
一時的なユーザー(テンポラリーユーザー)
ブラウザでBubbleアプリを開くとすぐにユーザーセッションが作成されます。
既にログインしているユーザーがクッキーをクリアしていない場合、セッションは以前と同じユーザーを使用しますが、新しいセッション(ログインしていないユーザー)の場合、一時的なユーザー(テンポラリーユーザー)が作成されます。
このユーザーは「ログインしていない」とマークされます(言い換えれば、「現在のユーザーはログインしていません」がyesで返答されるということです)。
一時的なユーザー(テンポラリーユーザー)はサインアップされたユーザーのように振る舞い、尚且つ変更することができ、アプリケーションのデータベースに保存されます。
ユーザーが同じブラウザを使用していてクッキーをクリアしていない場合、ユーザーのフィールドを変更するために使用した値はすべて同じになります。
しかし、Bubbleは自動的に一時的なユーザー(テンポラリーユーザー)データをクリアします。3日後にそのようなユーザーは削除され、ユーザーが同じブラウザでセッションを開くと、新しい一時的なユーザーが3日間作成されます。
ユーザーが最初にアプリケーションにアクセスしたとき、そのユーザーは一時的なユーザー(テンポラリーユーザー)とみなされます。
サインアップ・ワークフローを経ると、現在の一時的なユーザー(テンポラリーユーザー)はサインアップ・ユーザーとなり、データベースに永久に保存されます。
以上、ここまでがユーザータイプの説明でした。
Goggleを使うとき、ログインせずにブラウザから入るのか、もしくはアプリを使ってログインした状態で検索するのか、といった違いを想像すると、上記の説明をより深く理解することができたのではないかと思います。
さてここからは、OAuth(オーオース):Xを用いたログインについての説明です。
OAuth(オーオース):Xを用いたログイン
ログイン
OAuth(オーオース)っていう言葉、なかなか聞きなれないですよね…プログラミングの経験が豊富な方を除けば、ほぼ未知の言葉かと思います。
そしてこのOAuth(オーオース)という言葉を一言で説明できるほど簡単なモノでもないのですが、この後の説明を読んでもらえば、みなさんもちょくちょく出くわしている、あの状況のことか!と合点がいくと思います。
ユーザーを認証する最も一般的な方法は、パスワードや電子メールの入力を促すことです。
しかし、非常に多くの場合、他のサービスからの認証情報を使用してユーザーを認証するために、いくつかの外部サービスを使用することになるでしょう。
これはプラグインを使って行います。そうすることで、アプリを設計する際にいくつかの利点があります。以下では、Facebookを例に説明します(言い換えれば、アプリに「Facebookでログイン」ボタンがあるということです)。
これにより、ユーザーはアプリへの認証をより迅速に行うことができ、別のパスワードを覚える必要もありません。
通常、ほとんどのサービスでは、アプリが自分のIDを使用することを承認するために、簡単なワンクリック認証フローを提供しています。
例えば、「Login with Facebook」というボタンを1つ押す必要があり、ユーザーはFacebookからアプリが自分の資格情報を使用することを承認するように促されます。
これはまた、ユーザーに代わってサービスにいくつかの呼び出しを行うことができます。
Facebookを使用すると、(Facebookに登録されている)彼らの電子メールを取得することができ、彼らのFacebookのプロフィール写真を取得することもできます。
Bubbleでこのようなフローを設定する場合、アプリを機能させるためにユーザーからの権限レベルを定義する必要があります。
デフォルトでは、ほとんどのサービスでは、ユーザーが資格情報を使用してサードパーティのアプリケーションにサインアップしたときに、公開プロフィールと電子メールのみが公開されますが、より多くの権限を要求することができます。
つまり、電子メールや公開プロフィールのみならず、Facebook上のプロフィール写真を自動的にアプリに取り込むのか、もしくは取り込まないのかなどを設定できる、ということです。
注意点としては、ソーシャルログインのみを使用し、必要な場合にのみユーザーに対して許可を求めるようにしましょう。
一部のデータにアクセスするために許可を求めることは、ユーザーが敏感に反応することであり、サインアップの減少につながる可能性があります。
ユーザーがBubbleでソーシャルネットワーク(Facebook)にサインアップすると、データベースに新しいユーザーが作成されます。
主な違いは、一度ログアウトしたユーザーのログイン方法が、パスワードの入力ではなく(パスワードを定義していないので)、Facebookでログインする方法になることです。
ユーザーがブラウザでFacebookにログインし、アプリがFacebookログインを使用している場合、ユーザーは自動的に現在のFacebookユーザーとしてログインします。
従来のログインとソーシャルログイン
Bubbleのユーザーは、従来のログインとソーシャルログインを同時に利用することができます。ここにはいくつかのケースがあります。
①ユーザーが現在電子メールとパスワードでログインしている場合、アカウントをOauthプロバイダー(Facebook、Google…など)にリンクするように促すことができます。
ユーザーがこのようなフローを通過すると、新しいユーザーは作成されませんが、その代わりに、現在ログインしているユーザーにOauth資格情報が追加されます。
このフローが完了すると、ユーザーは電子メール/パスワードで、Oauthフローを介してログインできるようになります。
外部サービスによって提供された電子メールを使用してデータベースに別のユーザーが存在する場合、アクションは失敗し、メッセージがユーザーに表示されます。
②Oauthフローを通過する際にユーザーがログインしていない場合、同じメール(Facebookに登録されているメール)を持つユーザーがアプリのデータベースに既に存在する場合を除き、新しいユーザーが作成されます。
この場合、ワークフローは失敗し、ユーザーにメッセージが表示されます。
③ユーザーが外部サービスにサインアップし、アカウントにパスワードを追加したい場合、「ユーザーのパスワードをリセット」アクションを実行することでこれを行うことができます。
これにより、Oauth資格情報のみで認証していたユーザーが効果的に変更され、電子メールとパスワードの値がユーザーオブジェクトに変更されます。
OAuth(オーオース):Q&A
Oauthに関連するよくある質問
Q.Bubbleアプリにすでに存在するユーザーに新しいOauthサービスを追加するにはどうすればいいですか？
ユーザーがすでにサインインしている場合、Oauthサービスで「ソーシャルネットワークでのサインアップ/ログイン」を使用すると、そのサービス上のそのユーザーのアカウントとBubbleアプリのユーザー記録が「リンク」されます。
Q.リフレッシュトークンは自分で処理する必要がありますか？
一般的にはありません。
リフレッシュトークンを処理する必要がある場合の1つは、Oauthを有効にするために独自のプラグインや、API接続を構築している場合です。
たとえば、アプリでユーザーがGoogleに認証したとき、ユーザーのGoogleデータを使用して、ユーザーに代わってアプリがアクティブであるかどうかに関係なく、X時間ごとにメールをチェックするなどを行うことができます。
このような場合、Google Oauthを提供するプラグインではユースケースには十分ではありません。
Q.Oauth経由でサインアップしたユーザーが自動的にログアウトされ続けています。どのように対応したら良いでしょうか。
Oauth ログインには、エンドユーザーのセキュリティを向上させるために自然なタイムアウトが発生することがありますが、これは通常、数日またはそれ以上の時間がかかります。
ユーザーがより短い期間ログインしたままでいられない場合、リフレッシュ・トークン(Oauth権限付与が時間の経過とともに自動的に更新される方法)に何か問題があるかもしれません。
これらの問題は、使用しているプラグイン(またはAPI接続)やサードパーティ自体の設定に何か問題があることが多いので、デバッグするには厄介な問題です。
試すべきことは、同じサービスでOauthを提供する別のプラグインをインストールし、その新しいプラグインを介してテストユーザーをサインアップし、そのユーザーに同じ問題が発生するかどうかを確認することです。
それでも解決しない場合は、フォーラムが特定の Oauth プロバイダーの問題を解決した他のユーザーを明らかにすることができるかもしれません。
Q.特定のOauthサービスで使用しているプラグインを切り替えても、そのサービスでログインするすべてのユーザーの能力を維持できますか？
同じOauthサービスの異なるプラグインは、異なるOauthサービスのように扱われます。
例えば、プラグイン1とプラグイン2の両方でGoogleにサインアップ/ログインできる場合、プラグイン1からプラグイン2に切り替えても、すべてのユーザーがGoogleにログインできる機能は自動的には保持されません。
この移行を処理するには、 プラグイン1からプラグイン2に移行し、 しばらくの間、両方のプラグインをアプリにインストールしたままにしておきます。
ユーザーがログインしたら(プラグイン1経由など)、プラグイン2で「ソーシャルネットワークでサインアップ/ログイン」アクションを持つワークフローをキックオフするように促します。
これにより、2のOauthサービスがユーザーに関連付けられます。すべてのユーザーまたはほとんどのユーザーがこれを行った後、プラグイン1を削除しても問題ありません。
まとめ
OAuthという名前の響きは難しく聞こえがちですが、何か新しいアプリをダウンロードした際に、「Goggleを使ってログインする」や「Facebookを使ってログインする」という表示、のことかと考えてくれたら大丈夫です。
