こんにちは!
当社のアプリでアカウントを作成したユーザーに対して、Discourse への招待を送信しています。すでにユーザー名やコミュニティに必要なカスタムフィールドは取得できていますが、Discourse 側でユーザーが再度入力する必要があります。
これらのフィールドをプロフィール作成時に自動で埋めることは可能でしょうか?
よろしくお願いいたします!
こんにちは!
当社のアプリでアカウントを作成したユーザーに対して、Discourse への招待を送信しています。すでにユーザー名やコミュニティに必要なカスタムフィールドは取得できていますが、Discourse 側でユーザーが再度入力する必要があります。
これらのフィールドをプロフィール作成時に自動で埋めることは可能でしょうか?
よろしくお願いいたします!
アプリを SSO サーバーとして機能させるのが最善だと思います。それが望ましくない場合は、アプリから API を通じてユーザーを作成し、その設定を含めることも可能です。その方法は「Discourse API のリバースエンジニアリング方法」をご覧ください。
API 経由でユーザーを作成したくありません。ユーザー自身がパスワードを設定し、ユーザー名を選択したいからです。すべてのデータを含むステージングユーザーを作成する方法を検討しましたが、API ではそれができないようです。
考えられるもう一つの選択肢は、招待機能を拡張して、カスタムフィールドやプロフィール情報の入力を可能にすることです。
WebhookやAPI呼び出しを通じて、アプリからフィールドを取得するプラグインはいかがでしょうか?ユーザーレコードが更新された際に、プラグインが get yoursite/user/<email_address> のような処理を行い、ユーザーフィールドを自動で埋めるような仕組みです。SSOが依然として最善の解決策のように思えます。
はい、Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) をご確認ください。これはシングルサインオン(SSO)のまさにそのユースケースです。
ただし、SSO を使用する場合、ユーザーを招待する必要はありません。ユーザーは Discourse インスタンスにアクセスするだけで、すでにアプリにログインしていれば自動的にログインされます。もしアプリにログインしていない場合は、Discourse がログインのためにアプリへリダイレクトし、その後自動的に Discourse へ戻されます。
実は、Discourse を SSO プロバイダーとして使用しており、これまで順調に動作してきました。ただ、Discourse 側が SSO プロバイダーを利用する形であれば、より簡単になるという点には同意します。
@blake 私たちがSSOプロバイダーとしてDiscourseを使用しているため、これをどう実現するかまだ検討中です。現時点では、作業量が大幅に増えるため、他のものへの移行はしたくありません。他のアイデアはありますか?カスタムコードの作成が必要でも問題ありませんが、現在の設定に変更を最小限に抑えたいと考えています。
ありがとうございます!
設定とこれらの 2 つの文章に混乱しています。それでは「シングル」サインオンではなく、ダブルサインオンになってしまいますよね?
もし Discourse が SSO であるなら、アプリの新しいユーザーはまずアカウント作成のために Discourse へリダイレクトされ、認証後にアプリへ戻されるはずです。そうすればすべての情報が 1 か所に集約されます。
現在の理解に基づけば、アプリを SSO プロバイダーとして機能させ、Discourse からそれを利用するようにするか、あるいはアプリのユーザーをまず Discourse でサインアップさせ、その後アプリへリダイレクトするべきでしょう。現状はそれが設定されていないようですが。
あるいは、デュアルサインオン構成にしたいのであれば、ユーザーがアプリでサインアップした時点で、API を通じて自動的に Discourse 側でもユーザーを作成し、ユーザーに決して教えないランダムなパスワードを設定して、アプリで入力されたプロフィール情報を自動入力します。その後、招待メールを送る代わりに、Discourse のパスワードリセットページへ誘導します。
当社はアプリを通じて登録を行っていますが、アプリ自体にはセッション管理機能はありません。ユーザーの課金と情報のデータベースへの保存のみを行っています。
当社はユーザーにまずアカウント作成を必須とする必要がありますが、このステップを省略したいと考えています。できる限り簡単にしたいからです。
セッション管理、パスワード復元、2 段階認証、そして Discourse が提供するすべての機能を実装するのは多大な労力を要するため、そのような取り組みは避けたいと考えています。
それは当社の望むところではありません。
当初はこれを試しましたが、ランダムなユーザー名を設定する必要があり、それは望んでいません。動作はするものの、ユーザーがコミュニティを利用する前にアカウントをパーソナライズできるようにしたいと考えています。
まあ、答えはやはり外部の SSO プロバイダーを利用することになるでしょう。この方向で進め、Discourse をどう活用して希望通りに動かすかという思考は止めます。
@blake、ご助力ありがとうございます!
それとも、アプリを廃止して、Discourse Subscriptions に収益管理を任せるのはどうでしょうか?