When bulk adding users to a group using the interface described here, if an email in the input list does not exist in the discourse already, an invite email is sent.
If you click the link, you’re brought to an account creation page within Discourse:
If you fill out the form, you create an account. The created account has no SSO information
I think it’s pretty clear why this is a problem:
Bypassing our SSO authentication system is very bad.
Without a warning that “X people are about to get emailed”, I inadvertently spammed people because I didn’t realize messages were being sent.
Expected behavior:
When bulk adding to a group, if SSO is enabled, ignore any emails that aren’t already on the site.
Thanks for reporting this. I can reproduce the issue on my development site. When SSO is enabled, any emails that are not already on the site should be ignored if they are added to a group. We will get this fixed. Sorry for the trouble that it has caused.
@Grayden_Shand Actually we’re currently considering adding SSO auth on the invites redeem page instead. When redeeming the invite, the user will have to authenticate via SSO instead of filling up the sign up form. Will that fit your use case?
@sam I’m thinking about the invite flow and one thing I’m unsure of is whether the email which the invite was sent to has to match the SSO email? Seems like we could enforce this for email based invites but not for link based invites. WDYT?
For our use case, it would be a lot better to be able to suppress the invite emails entirely. For most of our sites (temporary communities for online courses), there is a limited window to sign up (and a fee). So, I imagine someone receiving an invite to the site, who then shows up and sees they can’t actually join anymore, would be frustrated. There’s really no circumstance where we want someone receiving an invite to one of our sites.
If you do go forward with this, I’d ask to also have you implement a warning with something to the effect of: “You are about to email XX people who are not users of your site: bob@example.com, alice@example.com, …” Then we could find those users and remove them from the bulk-add list.
Would you be able to use invite links then for your use case? That way it does not email anyone and you have an expiry date.
I still do support some ninja mode to bypass sending emails so you can add a big number of emails to an allow list, but I am curious if the invite link feature bypasses your need here.
I don’t think so, but maybe I’m not understanding the question correctly. Let me explain how we use Discourse, the SSO feature, and why I originally bumped into this bug…
We run an e-learning platform that uses a temporary discourse for each session of each workshop (course).
We use SSO with a custom auth system for two reasons:
so that a user only needs to create one set of credentials to access any course they’ve registered for.
to enforce policies on who is allowed in to each discourse based on arbitrary data in our database. For example in our discourse SSO endpoint, we check to make sure the user has a valid registration and that the date is within the bounds of our opening and closing dates.
I ran into this bug above when we wanted to create a group in one workshop only for people who were in a different one (like an alumni group). So I added the full class list from the different workshop to the bulk add modal, and accidentally sent invites to everyone on that list who hadn’t registered for the current workshop.
So, we really never would use the invite feature in Discourse (whether it’s by link or by email). If we did want an invite feature, we’d likely have to build it ourselves because there’s some business logic we’d want to layer on top of any invites we sent out. For example, if the workshop enrollment period was closed we’d want to display an error message on the link. Or maybe we’d want to include a discount in the link.
All this is to say that it works if we don’t have to use it, but we would really like to not have to worry about inadvertently sending emails to people without an account in that Discourse.
