We have a private site where: Local logins are disabled (Facebook and Google logins are configured) Staff must approve all new user accounts We have a large email mailing list and would like to “pre-approve” all the email addresses in this list. If a person comes to the site and tries to sign-up or login with a Facebook or Google account associated with an email in our pre-approval list, they don’t have to wait for a staff member to approve them and they can immediately start using the site. Ideally we would also be able to pre-configure group membership per email. Is this possible? Solutions that require using the Discourse API are welcome.

I’m afraid this isn’t going to work at all! Primarily because invites don’t work without local logins enabled. So, You’re probably looking at a very custom plugin that will handle all of this or an external authentication system to suffice your requirements.

Welcome, Steve! I think that if you pull in the addresses with an import script the Right Thing will happen. You’ll want to make sure that those users are not marked as active unless you want to risk flooding them with notifications and summaries. This should be reasonably easy from the console. I think it could be done via the API if you’re hosted somewhere. What does “Large” mean?

“Large” means about 5,000 - enough that we don’t want to manually type it in the UI somewhere. @pfaffman can you clarify a bit how I would create the users via the API? It looks like ‘password’ is a required field for creating users, which I assume can’t be done if I have local login disabled: POST /users To expand a bit on the use case, for others that might be considering something similar: We want to encourage users to login with their social account - many of the people we are working to get engaged in discourse are not tech-savy and we want them to know they don’t need to manage another username and password. However, the current invite by email feature in discourse requires a user to pick a password, which undermines our goal of keeping things simple for our users. Perhaps there is a different way to achieve our goal? I’m not averse to enabling local login if we need to, but I want invited users to clearly see that the can login with social and not need a password at all. Thanks all! I’m really excited about getting more people using discourse.

[image] stevewritescode: we want them to know they don’t need to manage another username and password. Allowing them not to create a password and requiring them to let you know what email address they use with social login just isn’t the same. They can still skip having a password if they use a social login. I often refuse to sign in with my gmail account (though less frequently now) and my wife almost always refuses such. Also, the login-with-email is really handy and means that you never need a password. But I digress. If the API requires a password, just generate a random one. Having a password that you don’t know and don’t need is pretty much the same as not having a password. At some point I made GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group · GitHub; I don’t promise that it works, but it should get you pretty close. You want to create non-activated users, so you’ll need to modify it, but it should be pretty clear what to remove. (If you just want the problem solved and have a budget, please feel free to contact me.)

[image] pfaffman: They can still skip having a password if they use a social login I have to admit I didn’t realize until close inspection that the password field is optional for users that accept email invites. You make a fair point that users should be able to choose if they want to use a different email and create a password. I would feel a lot better if the UI was clearer that the password is optional, especially when social login is enabled on the site. With the current UI someone would need to really not want to create a password in order to discover that this isn’t strictly required, in my opinion. I suppose I should roll up my sleeves and make a PR to improve the UX :wink: I took a look at the example code, thank you! For what it’s worth, I needed to use this hack to make the appropriate API calls: Using the API to create a user on an SSO only system - #13 by DylannCordel - even still, I don’t think this meets the use case I had in mind because it triggers an email to the user for activation, which I had hoped to avoid in favor of a seemless “just works” experience if/when they eventually come to login to the site. I also played around a bit with this solution: How to manually add user in discourse? - #10 - I think it would work out to hack in the user accounts that I want to exist using this method, but ultimately I’m not sure it’s worth the risk for me to be directly modifying the environment inside the container to make these modifications. So, all in all, I think the workflow I was hoping for isn’t really a supported/expected workflow, and I’ll have to be ok with that until the UI gets improved (maybe) at some point. Thanks all!

You’re mixing up a few different things here. social logins skip password since auth is handled by facebook, twitter, google, etc invites make password temporarily optional but you have to follow the invite link again to “log in” which I think we locked down so much that effectively doesn’t work any more. You’d need to submit a password reset via email to get in after that, which requires setting a password. It’s a long story but invites are designed to get people in and replying ASAP with a minimum of fuss, but they are NOT intended to let people skip setting a password forever.

[image] codinghorror: I think we locked down so much that effectively doesn’t work any more This much seems to work: Send an email invite to a user (local login must be enabled for this to be available) When the user clicks the invite, they can leave the password blank and immediately get logged in. Next time they visit the site and need to login, they can login with a social account that matches that email. Now, it’s fair to say that maybe this shouldn’t work and that my earlier comment about unclear UI is actually a feature and not a bug designed to discourage people from utilizing this workaround. That said, it seems like it’s an ok path for a user to take if they are invited by email but ultimately don’t want to create a password and prefer the other benefits of social login (i.e. copying over their profile picture). I definitely understand the earlier point that some users actively want a password instead of social login and I’m convinced that I shouldn’t disable that for people that want it. I’m still hoping, though, for an easy and clear path for inviting or otherwise setting up users that would prefer not to have a password.

That path is fine, just realize the no password case is temporary for the reasons previously stated. So the user would need to do “something” in any case, there is no permanent status quo of no password at all.

Makes sense. Eventually the user needs to create a password or connect their social account. Thanks!

Pre-approving new users when local login is disabled

Product Support

pfaffman (Jay Pfaffman) August 22, 2019, 1:45pm 11

If you’re happy with email login (or social logins) you never need a password.

Topic		Replies	Views
Invitations should be compatible with SSO Feature invites	29	7634	April 21, 2022
Auto-activate new users Product Support	25	5008	September 21, 2020
Can I add users to Discourse without sending invites? Product Support	5	1528	April 29, 2020
Nutzer manuell per Email einladen aber ohne Registration? Product Support	4	372	August 18, 2025
How to switch from Discourse Connect SSO to local logins Product Support	1	1027	November 3, 2021

Pre-approving new users when local login is disabled

Related topics