Hello!
We are sending a Discourse invite to our users once they create an account on our app. We already have their name and custom fields we require for our community, but the user has to type these again on Discourse.
Is there a way for us to complete those fields as part of their profile?
Thanks!
I think best would be for your app to be the SSO server. If you don’t want that, then you can have your app create the user via the API and include those settings. You can figure out how to do that with How to reverse engineer the Discourse API.
We don’t want to create users via API because we want user to create a password and choose their username. I was looking into creating a staged user with all the data but seems this is not possible via API.
The other option I can think of is extending invites to allow custom fields and profile info.
Maybe a plugin that pulls the fields from your app via a webhook/api call? You could have the plugin do something like get yoursite/user/<email_address> and populate the user fields when the user record is updated. Something like that. SSO still seems like the best answer.
Yes, please checkout Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). This is the exact use case for Single Sign On.
With SSO though, you woudn’t need to invite them. They would just visit your discourse instance and be automatically logged in if they are already logged into your app. If they are not already logged into your app, discourse will redirect to your app for login, and then they will be auto-redirected back to discourse.
The thing is we are using discourse as our SSO provider and this has been working good for us, but yeah I agree this would be easier if Discourse consumes a SSO provider.
@blake I’m still thinking how we can do this since we are using Discourse as our SSO provider. I don’t want to migrate to something else at the moment because it will be a lot more work. Do you have other ideas? Is not a problem if we have to write custom code, but want to make the least amount of changes to how we have things setup.
Thanks!
I’m just confused by your setup and these two sentences because then you don’t really have Single-sign-on you have double-sign-on?
If Discourse was your SSO new users of your app should redirect to discourse first for them to create an account, and then redirect back to your app, once they are authenticated. Then all the info is in a single place.
Then based on my current understanding I would turn your app into a sso provider and have discourse consume it. Or forward users of your app to sign up first in discourse and redirect back to your app, because apparently this isn’t how it is setup currently?
Otherwise if you want to have a dual-sign-on setup, once they sign up in your app, automatically via the api create them as a user in discourse with a random password that you don’t ever give the user and auto fill their profile info that they filled out in your app. Then send them to the password reset page on discourse for their new account instead of sending them an invite.
We do the registration through our app, but our app doesn’t have session management. We just charge the user and store their information in our database.
We will need to require the user to first create an account, and this is the step we are taking away, because we want to make it as easier as possible.
This is the effort we don’t want to get into, because adding session management, passsword recovery, 2fa authentication and all the features Discourse provides will take a lot of work.
This is not what we want.
This is what I initially did, but we have to set a random username and this is not what we want. While it will work, we want the user to still be able to personalize their account before start using the community.
But yeah, I guess the answer is still to use an external SSO provider. I’ll go this route and stop thinking about how to leverage Discourse and making it work the way we want.
Thanks for the help @blake!
Or do away with your app and let Discourse Subscriptions handle the money?