We would like to integrate Discourse into our existing systems, to remove reliance on our Discord server for support. We already have our own account system setup, and would like to reuse it if possible to reduce friction. However email addresses are not required to be unique in our case, only usernames. It seems as though Discourse relies on the assumption that emails will be globally unique, which prevents us from directly integrating.
I checked out DiscorseConnect which seemed promising, but states:
Discourse uses emails to map external users to Discourse users
Which would not work in our case, as multiple accounts can (and do) use the same email address.
We then looked into Discourse OAuth2 Basic which at first glance did not require an email:
The only mandatory attribute is id
However later on it still mentions manually inputting an email address later if not provided by the oauth source:
Notice I omitted the email path: SoundCloud do not provide an email so the user will have to provide and verify this when they sign up the first time on Discourse
Would using Discourse still be something viable in our case? Having users manually provide an email address when logging in to Discourse for the first time would be fine in our case, but only if we can disable the ability to use an email address during the actual login process (requiring the use of only the username and password), since we can’t reliably map an email to a unique user. Being able to disable that from the login form entirely would remove friction on our end since it wouldn’t be something we’d support anyway, and would like to prevent users from even trying to do so.
We considered this but wasn’t sure how it would affect the oauth flow or if it would add friction to signup/sign in. This kind of change would be invisible to the user, so they’d fail to login unless they enter this modified email address. Our current account server would also be unaware of these modifications, so even if they entered the modified email we wouldn’t be able to find it in our records?
This would also break users already using email aliases, would it not?
Well, yes. Of course that would be the case, and is what I’m targeting. I was looking for a solution that just disallowed login with an email at all, leaving username logins as the only method. I’m fine with essentially breaking email support entirely (no email notifications for example) by just giving totally fake emails from the oauth server. But that creates friction if the ability to use an email to login is still available, since users would attempt to do so and fail.
That would essentially force us to track 2 separate emails per user, which isn’t desirable either, and as mentioned by @supermathie is not even guaranteed to work with all providers, and still causes friction as we would have to now tell users about this forum-specific email address they have to remember.
Yes, that would work technically. But for obvious reasons would not be a real solution to use, as it would block all others from ever joining the forum.
This isn’t something we can do for technical reasons. The most obvious of which being that we already have users who have the same email address as other accounts. But the bigger one is that we simply can’t do this. The project we are looking to incorporate Discourse into is Pretendo Network, a server emulation project for Nintendo Network. Nintendo allowed their account system to reuse email addresses, and so to emulate the servers accurately we have to as well. Forcing unique emails is just not in our cards.
Someone on my team suggested we run our own SMTP server which handles mapping the fake emails for Discourse to our users actual emails, forwarding the emails sent from Discourse that way. Which would work, but obviously comes at a higher technical cost to us and still does not solve the issue of disabling email login and the aforementioned friction that comes with our case.
It seems like we may just have to fork Discourse or use another forum solution to do what we need.
I’m going from memory here, but you can use DiscourseConnect with fake but unique email addresses. If usernames are guaranteed to be unique on your end, the implementation could be quite simple. The email address could be set to something like username@invalid.com.
Users would log into your system with whatever method they are using now. Your system would then generate the SSO payload with the fake email address.
The downside of this approach is that you would need to disable emails on Discourse. That can be done by setting the disable emails setting to either yes or to non-staff (If your staff members have unique email addresses).
You could also consider using + based email addresses for users with duplicate email addresses. The last time I checked, Discourse considered plus email addresses to be unique. Just make sure you URL encode the email addresses before using them in the DiscourseConnect payload. The risk here is that if users have duplicate email addresses and use an email server that doesn’t support + based email addresses, they won’t get emails from Discourse, but it would allow your other users to get Discourse emails.
Yes, but only for a particular case. If a user has created a Discourse account prior to the Discourse site having implemented DiscourseConnect, Discourse will attempt to associate existing users with the email address that’s in the DiscourseConnect payload. If you’re starting a new Discourse site, that won’t be an issue.
One other case where I’ve seen the email mapping issue come up is when due to some faulty code on the auth provider site, SSO records on the Discourse site became corrupted. In that case, the site was able to delete all SSO records on the Discourse end, then have Discourse associate users with the SSO payload email address the next time they logged in. Discourse then generated new SSO records for the users. This would still work with fake email addresses.
The logic with DiscourseConnect authentication is that Discourse first attempts to find the user based on the payload’s external_id field, if it doesn’t find a user, it falls back to trying to find the user based on the payload’s email field, if it still doesn’t find a user, it throws an error.
Double check all of this before actually implementing it on a live site, but I know that the fake email approach has been used on production sites for cases where user’s real email addresses can’t be shared with the Discourse site.
@simon Thank you for the information! This is starting to sound like we’re getting somewhere
This is fine, and I did mention earlier that this is an acceptable solution for the “all emails must be unique” problem. I am perfectly fine with essentially disabling emails in our case, and using fake emails was a solution I came to before making this post.
I may not have been clear originally, but the point of the post was seeing if it’s possible to force the login prompt to only accept usernames, since currently login can be done with either a username or an email. If email logins are still displayed as being available on the login prompt on Discourse, then our users may try to use their existing account email address and be met with an error. So either we would have to just deal with people trying, and failing, to use their current email address or somehow make the user aware of their new forum-specific one. Both of those can cause confusion and friction for users, so ideally we could simply restrict the login prompt to only accept usernames.
Staff having unique emails is unfortunately not guaranteed either so I would wouldn’t want to rely on it. Does this setting only disable email sending? Or does it disable email usage as a whole, like what I’m looking for with the login prompt?
I looked over the DiscourseConnect page several times and didn’t see this option there. Is there perhaps a better place to see this kind of documentation? I didn’t see any links to any full documentation on that post, so I just assumed that all the information there was all there was.
I will admit that I have not actually set up DiscourseConnect myself to dig through the settings. I was hoping that the documentation would be enough to grasp what can and can’t be done, so that we wouldn’t have to setup a whole test instance of the forum unless we knew we were going to commit to it. But it seems like there’s still some information not readily available, unless I missed something obvious?
This was also considered earlier in this thread, but the issue still remains that we would have to either deal with failed email logins or tell the user about this new forum email address. Removing that friction was my main goal. If that’s not possible to do here without forking Discourse itself, and the only solution is to either deal with failed email logins or give people a new email to remember, then we may be better off with a different forum solution.
I did misunderstand that it seems, that’s not super clear based on the post itself. However my point for bringing that up was to illustrate the reliance on emails being unique, which would still be an issue.
This DEFINITELY was not clear based on the post alone, unless I missed something. Thank you for that clarification! That sounds more in line with what I was hoping for.
As far as I know, it’s not possible to force the Discourse login prompt to only display the username field. You’d also be stuck trying to figure out how to get user’s registered in the first place. That’s why I’m suggesting DiscourseConnect.
When DiscourseConnect is enabled, it become the only authentication system for your Discourse site. When users click the login button on Discourse, they’ll be automatically redirect to the URL that you’ve added to the discourse_connect_url site setting. Your auth system takes over from there. That means that if you have a site that users can currently login to with username and passwords, they’ll keep logging in that way.
If adding code to your current site isn’t possible, you could also create a small web site that users can login to with usernames and passwords, then add the DiscourseConnect code to that site. It would be less work than forking Discourse.
Thank you! It seems I had a fundamental misunderstanding of DiscourseConnect. I was under the impression that the login page stayed on Discourse, and it simply reached out to the external server. I was not aware that the user was directed to a different login page of our choosing entirely.
My misunderstanding of DiscourseConnect seems to have been the crux of this issue and all the confusion.
If you don’t care about discourse sending email for notifications then you could have your sso give discourse game-username@bogus.invalid as the email address.
It might be possible then for users to add second real email address and then switch the bogus one to the secondary.
I had not. Like I said earlier, we did not want to go through with a test deployment until we knew Discourse was usable. So I had not actually tried anything, so far we’ve just been reading on your features and asking here when things aren’t clear. That’s actually fantastic to hear, I was not aware we could control things to that degree
Honestly, it seems rather difficult to find real documentation on anything outside of the API. At least coming from the perspective of a first time user.
There’s nothing obvious on the Discourse homepage that would link to any documentation, and all links on the DiscourseConnect page either link to unrelated pages or back to the post itself. Trying to search for “Discourse documentation” on search engines just leads to pages like documentation - Discourse Meta, which is just the forum category for it not a real docs page, and https://docs.discourse.org/ but this is the API documentation and doesn’t have anything on it regarding features like DiscourseConnect it seems.
Trying to organically find this information has proven. Difficult.
Is there some obvious place I’ve just missed where all of this is gone over? It seems like the closest I can find is the forum category, as there’s many guides/how-tos written by staff and the like about various topics. But reusing the forum to document itself didn’t sound right to me? Is there no dedicated documentation source for Discourse features/tools like there is for the Discourse API?
Correct, that would work. As stated a few times now, using a bogus email from the oauth provider was something we came to before even making this post.
But that alone does not solve the issue of “if a user sees in the login prompt that emails are accepted they would try to use them and fail due to having a bogus email”.
However I just had a misunderstanding of how DiscourseConnect works. I was under the impression the login form was still on Discourse, and that Discourse simply reached out to the oauth provider. @simon has corrected this for me now, I as not aware that it physically moved the user off site to our own login form. That alone solves basically all issues I had. Thank you, though!
None of the people I’ve worked with has been unhappy with discourse.org hosting. If you need to self-host for some reason, you can sign in to https://dashboard.literatecomputing.com/ and join the “free trial” group and use the Dashboard for free (if you can’t figure out how join the free trial group then you’ll likely need more support than I’m willing to give). If you’re willing to use Digital Ocean and mailgun you need only enter API keys and a hostname.
I embarrassingly did not even think of this option! That is a good point and we will likely go through with that for testing purposes.
I had looked at your hosting options earlier today, as that would be easier than self hosting, but it seems largely out of our budget unfortunately. We have over 200,000 users, so the “Basic” plan is not an option. We have more than 5 staff, so the “Standard” plan is not an option. And as an FOSS project we operate on donations, and barely make enough to keep the lights on and pay for a single full time developer, so the “Business” plan is very out of reach.
Using the trial for testing purposes is a fantastic idea however, thank you! We already self host most of our services anyway, even down to our Mastodon instance, so self hosting Discourse is not a huge hurdle.
Of course! Always happy to help if I can, even if just by giving some feedback. I hope it didn’t come off as too negative, as that wasn’t the intent to be clear.
If you’re interested, we offer free hosting for some FOSS projects… your staff numbers are higher than our limits, but the people making the decision might be able to let that slide.
(note our definition of “staff” here is “Admins” + “Site-wide moderators”, not “staff at the respective company” - I’d be curious what the definition of staff in your head was prior to this)
Thank you! I had missed this on your pricing page. I just went back to double check and it’s buried deep at the bottom of the page I’ll look this over and talk with my people!
Our definition of “staff” in this case covers 2 broad roles:
People on our core development team (as an open source project this can fluctuate, as people may come and go, but we’ve had ~5-10 active developers over the years at any given time)
Our moderation team (non-developers and community members who moderate our services, such as online matches and our Miiverse implementation, as well as our Discord server). This also varies
We COULD limit this to just 5 of our developers, which would fit within those limits, but would require us to decide who does and doesn’t get full rights on the forum. It would also limit the number of people able to moderate the forums (we introduced a moderation team outside of the development team in order to take this load off of just us in the first place)
I will definitely bring this up with people on my side and see where things go!
I’ll look this over and talk with my people!