Greetings,
I am trying to find a way to allow admin users to create accounts, without providing a password and then emailing a register link to provided emails. Basically, to block registration completely and only allow it to happen through manual action from an administrator.
I am wondering what a good way to implement this would be. My ideas so far are
Generate a random password and send that in the email, forcing the user to go through the reset password flow afterwards.
Figuring out a way to create an invite link and send that.
The first option seems a bit insecure so I would like to avoid that. In regards to the second option i am a bit unsure if it is possible. How would I go about doing that?
Based on the current functionality provided by strapi, the first option you suggested is the best one. I’d suggest using the same password for all newly created uses though. You can enforce this using the beforeCreate lifecycle hook. Just set the password to your choice before hand. Using the same password will be important since you can run a cron job at a time frame of your choice that sends users reminder emails to reset their password (strapi-email plugin) or deletes the user if a certain amount of time has passed. This should minimise security issues as much as possible. You can also implement the afterCreate lifecycle hook for sending users emails confirming their registration via resetting their password.
Another option would be to make use of third-party authentication. This doesn’t adhere to the requirement of users not being able to register though. You could choose a provider that most of your userbase already uses. You could then create a content-type that holds the emails of all users that should be able to access the application. This content-type controller will have an API method that should be called before initiating the OAuth2.0 login/register process. If the users email does not exist within the content type entries, you don’t allow them to register. This will probably be the safest option in terms of security but I’m not sure how your frontend is implemented and if third-party authentication is viable.
Let me know if you need anymore clarity in terms of the options I’ve provided.
I’m glad you mentioned the second option, because we are focusing on using OAuth2.0 and had that idea, but for some reason It felt like something you shouldn’t do. With confirmation from someone else I can comfortably go with that implementation.
@Faiyaaz_Khan So if I am to go with the second option, should that check happen on the frontend? I am trying to figure out how to reject a user in beforeCreate hook of the users model. So far the only solution seems to be to throw an error, but that seems a bit hacky.
Would it be better to try and modify the User service using extensions, or do the check on the frontend?