Userテーブルのemailは他のレコードと重複できないため、
Userテーブルに「email1」などのカラムを追加しておき、
会員登録時に以下の登録をすることを考えました。
これにより、同じメールアドレスで2つ以上のUserの会員登録ができると考えたのですが、
メールの受信が確認できていないためなのか、
Userテーブルにレコードが登録されるものの、認証されていないUserとして扱われてしまいます。
(Search for Userで認識されない、パスワード再発行のメールが送信できないなど)
1つのbubbleアプリで2つの異なるサービスを開発する方法があれば教えていただけますでしょうか…?
気になったのですが、ひとつのアプリで異なるサービスを運用しなければならない理由はどんなものでしょうか?
Bubbleの仕様から考えても、ひとつのアプリではひとつのサービスを運用することが前提に作られています。
仮に、書かれているような流れでログイン周りの処理が実装できたとしても、
そのような方法で無理に2つのサービスを運用すると、セキュリティ上の脆弱性が出てきかねません。
ですので、ひとつのアプリではひとつのサービスを運用することをおススメします。
「いいね!」 2
ご意見いただき、ありがとうございます!
理由は以下の通りでございます。
- 将来これらのサービスを統合する可能性があるため
- bubble利用費を節約するため
1つのアプリで運用できる方法が見つかりましたら、いただいたご意見を参考に
1つで運用するデメリットが大きいそうでしたら諦めたいと思います!
「いいね!」 1
基本は1つのBubbleアプリに1つのサービスですが、サービス統合を視野に入れているなら、
emailカラムは1つにして、どのサービスに所属するかを新たにカラムで持たせて、ログイン時に判断するのはどうでしょうか。
「いいね!」 4
ご意見いただき、ありがとうございます!
emailカラムは1つにして、
Userレコードは1つで複数のサービスアカウントを管理すると理解でしょうか。
下記に課題がありそうですが、解決策がありそうでしたら教えていただけると幸いです
- 「同じメールアドレスで2つ以上のUserの会員登録ができる」が実現できなさそう
- サービスAでログインするとサービスBもログイン状態になってしまう
- パスワードがサービスAとBで統一されてしまう
Bubbleの基本的な思想として、何らかの単一サービスを作るためのプラットフォームとなっています。
そのため、1アプリケーション1サービスが原則です。
bubbleのユーザーアカウントの性質上、同一メールアドレスでログインさせる場合はパスワードは必ず一つです。
抜け道的には、下記方法は取れると思います。
ユーザーアカウントのメールアドレスはサロゲートなアドレスとして扱う(登楼されているemailアドレスにはメールを送れない)ような設計にしたら良いのではないでしょうか?
例としては、
サービスA,サービスBがあるとき、登録されたメールアドレスuser@hogehoge.comだとしたときに、
bubbleのuserテーブルには
a-user@hogehoge.com
b-user@hogehoge.com
のように登録させる形です。
話を見ている限りサービスごとにログイン画面は異なると思われますので、サービスA用のログイン画面からの場合はa-をメールアドレスに追加した上でsigninさせる・・・というような実装が必要になります。
また、Bubble標準のEmail Validateは使用できないので、そういった昨日が必要な場合は独自実装が必要です。
そもそも懸念点が非常に多いため、パーソナルプランなどで2つアプリケーションを作るほうが良いのではと思いますが・・・
「いいね!」 4
ありがとうございます!
また、Bubble標準のEmail Validateは使用できないので、そういった昨日が必要な場合は独自実装が必要です。
Email Validateを無効化する設定がありそうでしたら教えていただけますでしょうか…?
bubbleのuserテーブルには
a-user@hogehoge.com
b-user@hogehoge.com
のように登録させる形です。
a-user@hogehoge.com、b-user@hogehoge.comでメールの受信が確認できない場合、
Userテーブルにレコードが登録されるものの、認証されていないUserとして扱われてしまうので
(Search for Userで認識されない、パスワード再発行のメールが送信できないなど)
Email Validateを無効化が必要かと思います。
Bubble標準のValidate処理を使わなければ良いので、
Send confirmation emailなどは使用せずに、自身でフローなどを設計して組み込む形になります。
おそらくこのアイデアの段階で実装の想像がつかないようでしたら、1アプリケーションに複数のサービスを混在させると開発が難しいと思いますので、異なるアプリケーションに分けることをおすすめします。。
「いいね!」 5
ご回答いただきありがとうございます!
理解が深まり、感謝いたします。
そうですね、ネックが多数ありますので今回は1つのbubbleアプリで2つの異なるサービスを開発することは見送りたいと思います。
みなさま、貴重なご意見をいただき誠にありがとうございました!
メールアドレスをカスタマイズしたとき、パスワードを忘れた時に再セットメールを送れなくなる懸念はありますよ。
「いいね!」 1