おすすめ記事

おすすめ記事一覧

Bubble・ユーザータイプ・OAuth(オーオース):X を用いたログイン

ノーコードでWebアプリ作成 ~Bubble編~|濱口 まさみつ|note

みなさんごきげんよう。オフィスに差し込む西陽と富士山がキレイな木曜日の午後、いかがお過ごしでしょうか。外と中の寒暖差にはお気を付けください。この記事では、ノーコードツール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アクションによってユーザーが削除されると、そのユーザーはデータベースに存在しなくなり、ログインなどができなくなることに注意してください。 

現在のユーザーのコンセプト

あなたが使用できる最も重要なデータソースの一つは、「現在のユーザー」です。これは現在アプリケーションを使用しているユーザー(データベース内の別のユーザーと比較して)を記述します。セッションとは、ある時間にアプリケーションを使用しているユーザーの概念を記述したものです。技術的には、セッションはブラウザレベルのクッキーによって定義されます。アプリの設定によっては、これらのクッキーの有効期限を設定することができます。一般的に、このようなクッキーは無限であるため、 ユーザーはログアウトするか、クッキーをクリアするまで同じセッションにいることになります (Facebookと同様に、ログアウトするか、別のブラウザを使用するまで永久にログインしていることになります)。

状況に応じて、現在のユーザーは登録ユーザー、サインアップユーザー、一時的なユーザー(テンポラリーユーザー)のいずれかになります。

サインアップユーザー

ユーザーが(電子メールとパスワードで)bubbleにサインアップした場合、この電子メールとパスワードを使用してデータベースに永続的なエントリーが作成されます。ユーザーが新しいブラウザ(クッキーなし)でアプリを開き、ログインワークフローでその人に関する情報(メールやパスワード)を入力すると、ログインされます。「現在のユーザーはログインしています」の値はyesとして返答されます。現在のユーザーを変更した場合、これはデータベースオブジェクトに永続的に保存され、ユーザーが別のデバイスでアプリにログインした場合、そのユーザーのアカウントにも変更が適用されます。(GoggleやFacebookに別デバイスからログインしたときにメールでお知らせが来る、あの状態のことです)

この重要な結果の一つは、データベース内の検索で見つけられるすべてのユーザーは、永久アカウントであるため、サーバー上で「ログインしている」とマークされるということです。

一時的なユーザー(テンポラリーユーザー)

ブラウザでbubbleアプリを開くとすぐにユーザーセッションが作成されます。既にログインしているユーザーがクッキーをクリアしていない場合、セッションは以前と同じユーザーを使用しますが、新しいセッション(ログインしていないユーザー)の場合、一時的なユーザー(テンポラリーユーザー)が作成されます。このユーザーは「ログインしていない」とマークされます(言い換えれば、「現在のユーザーはログインしていません」がyesで返答される、ということです)。

一時的なユーザー(テンポラリーユーザー)はサインアップされたユーザーのように振る舞い、変更することができ、アプリケーションのデータベースに保存されます。ユーザーが同じブラウザを使用していてクッキーをクリアしていない場合、ユーザーのフィールドを変更するために使用した値はすべて同じになります。しかし、 bubbleは自動的に一時的なユーザー(テンポラリーユーザー)データをクリアします。3日後にそのようなユーザーは削除され、ユーザーが同じブラウザでセッションを開くと、新しい一時的なユーザーが3日間作成されます。 

ユーザーが最初にアプリケーションにアクセスしたとき、そのユーザーは一時的なユーザー(テンポラリーユーザー)とみなされます。サインアップ・ワークフローを経ると、現在の一時的なユーザー(テンポラリーユーザー)はサインアップ・ユーザーとなり、データベースに永久に保存されます。

以上、ここまでがユーザータイプの説明でした。 Goggleを使うとき、ログインせずにブラウザから入るのか、もしくはアプリを使ってログインした状態で検索するのか、といった違いを想像する と、上記の説明をより深く理解することができたのではないかと思います。さてここからは、OAuth(オーオース):X を用いたログインについての説明です。張り切って後半もLet’s Go!

What is OAuth? Definition and How it Works

OAuth(オーオース):X を用いたログイン

ログイン

OAuth(オーオース)っていう言葉、なかなか聞きなれないですよね…プログラミングの経験が豊富な方を除けば、ほぼ未知の言葉かと思います。そしてこのOAuth(オーオース)、一言で説明できるほど簡単なモノでもないのですが、この後の説明を読んでもらえば、 みなさんもちょくちょく出くわしている、あの状況のことか!と合点がいく と思います。ということで、bubble内のOAuth(オーオース)についての解説をじっくりとしたいと思います。

ユーザーを認証する最も一般的な方法は、パスワードや電子メールの入力を促すことです。しかし、非常に多くの場合、他のサービスからの認証情報を使用してユーザーを認証するために、いくつかの外部サービスを使用することになるでしょう。 (何か新しいアプリをダウンロードした際に、「Goggleを使ってログインする」や「Facebookを使ってログインする」という表示を見たことがあるかと思います) これはプラグインを使って行います。そうすることで、アプリを設計する際にいくつかの利点があります。以下では、Facebookを例に説明します(言い換えれば、アプリに「Facebookでログイン」ボタンがあるということです)。

これにより、ユーザーはアプリへの認証をより迅速に行うことができ、別のパスワードを覚える必要もありません。通常、ほとんどのサービスでは、アプリが自分のIDを使用することを承認するために、簡単なワンクリック認証フローを提供しています。 例えば、「Login with Facebook」というボタンを1つ押す必要があり、ユーザーはFacebookからアプリが自分の資格情報を使用することを承認するように促されます。 

これはまた、ユーザーに代わってサービスにいくつかの呼び出しを行うことができます。Facebookを使用すると、これは、(Facebookに登録されている)彼らの電子メールを取得することができます、彼らのFacebookのプロフィール写真を取得することもできます。

bubbleでこのようなフローを設定する場合、アプリを機能させるためにユーザーからの権限レベルを定義する必要があります。デフォルト(最初の状態)では、ほとんどのサービスでは、ユーザーが資格情報を使用してサードパーティのアプリケーションにサインアップしたときに、公開プロフィールと電子メールのみが公開されますが、より多くの権限を要求することができます。 (つまり、電子メールや公開プロフィールのみならず、Facebook上のプロフィール写真を自動的にアプリに取り込むのか、もしくは取り込まないのかなどを設定できる、ということです)。

注意点としては、ソーシャルログインのみを使用し、 必要な場合にのみユーザーに対して許可を求めるようにしましょう 。一部のデータにアクセスするために許可を求めることは、ユーザーが敏感に反応することであり、サインアップの減少につながる可能性があります。

ユーザーがbubbleでソーシャルネットワーク(Facebook)にサインアップすると、データベースに新しいユーザーが作成されます。主な違いは、一度ログアウトしたユーザーのログイン方法が、パスワードの入力ではなく(パスワードを定義していないので)、Facebookでログインする方法になることです。ユーザーがブラウザでFacebookにログインし、アプリがFacebookログインを使用している場合、ユーザーは自動的に現在のFacebookユーザーとしてログインします。

従来のログインとソーシャルログイン

bubbleのユーザーは、従来のログインとソーシャルログインを同時に利用することができます。ここにはいくつかのケースがあります。

1,ユーザーが現在電子メールとパスワードでログインしている場合、アカウントを Oauth プロバイダー (Facebook、Google … など) にリンクするように促すことができます。ユーザーがこのようなフローを通過すると、新しいユーザーは作成されませんが、その代わりに、現在ログインしているユーザーに Oauth 資格情報が追加されます。このフローが完了すると、ユーザーは電子メール/パスワードで、またはOauthフローを介してログインできるようになります。外部サービスによって提供された電子メールを使用してデータベースに別のユーザーが存在する場合、アクションは失敗し、メッセージがユーザーに表示されます。

2,Oauthフローを通過する際にユーザーがログインしていない場合、同じメール(Facebookに登録されているメール)を持つユーザーがアプリのデータベースに既に存在する場合を除き、新しいユーザーが作成されます。この場合、ワークフローは失敗し、ユーザーにメッセージが表示されます。

3, ユーザーが外部サービスにサインアップし、アカウントにパスワードを追加したい場合、「ユーザーのパスワードをリセット」アクションを実行することでこれを行うことができます。これにより、Oauth 資格情報のみで認証していたユーザーが効果的に変更され、電子メールとパスワードの値がユーザーオブジェクトに変更されます。

OAuth(オーオース):Q and 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に関する説明を読み解くのはハードだったかもしれません。OAuthという名前の響きは難しく聞こえがちですが、何か新しいアプリをダウンロードした際に、「Goggleを使ってログインする」や「Facebookを使ってログインする」という表示、のことか理解すれば、比較的とっつきやすい項目だと思います。それではまた別の記事でお会いしましょう。See You Soon!

 

 

 

 

 

 

 

 

 

 

 

 

 

Katsu

Katsu

高校まで日本で育ち、大学からアメリカ・ニューヨークへ。マスメディア、ジャーナリズム、インターネットメディア戦略を専門に修学。コロナ禍でオンライン主体になりつつある世の中で、記事が何かの手助けになれば幸いです。







関連記事

  1. Adalo Resource・ データの変更、条件付きアクション、トリガー通知(アクションセクション…

  2. 記事作成

    Bubble・オプションセット、エレメントカスタムステート

  3. 記事作成

    Bubble・SEO(検索エンジン最適化)

  4. Adalo Resource・Appleを使ってサインイン(スクリーンとコンポーネントセクション)に…

  5. 特集記事

    ノーコードで爆速モバイルアプリ作成!オススメツールを紹介

  6. Bubble

    .bubble(バブル)のプライバシールールを日本語訳解説

  7. 記事画像

    発注者も必見!ノーコードツールで開発を行うメリット13個

  8. SaaSロゴ

    Husky(Jungleworks)

  9. 記事作成

    Bubble・Slack(スラック)&Box(ボックス)

人気記事

  1. topimage
  2. 記事画像
  3. 特集記事
  4. top_image

おすすめ記事一覧

  1. Bubble
  2. 記事画像
  3. 勤怠管理
  4. Productivity
  5. 記事画像
PAGE TOP