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.
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.
“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.
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 https://github.com/pfaffman/discourse-user-creator; 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.)
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
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 - 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? - 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.
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.
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.
