mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-11 17:41:29 -05:00
Implement poor man's invitation-only registration #3651
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#3651
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mprasil on GitHub (Jun 12, 2018).
In current state one can either enable or disable user registration. I think it should be possible to implement some exception to the rule:
Admin and Owner of the Organization should be able to invite users not currently registered. For these special record would be made (possibly in a separate table?) that would allow registration of an user with specified email even if the registration is otherwise turned off. That way admin could turn off the self-registration, but he could still invite users if needed without having to restart Bitwarden to enable/disable it as it is implemented right now.
I'm not sure if I understand the invitation process on the client side properly, but I think it shouldn't clash with how it works right now.
Any thoughts?
@dani-garcia commented on GitHub (Jun 12, 2018):
I thought about a similar solution to yours some time ago. The problem is that we don't validate emails at all, so anyone that knows the email of the invited user could register an account first.
I guess the danger of that would be pretty low, knowing the user needs to be confirmed by an admin o owner to have access to the organization, so I'm okay with implementing this as long as there is a way to disable it.
Your idea seems alright, we would need to create a table for the invites (with email, organization id, user type, and collections the user can access) and basically delay the creation of the userorganization until the user is created. The problem with this is the invites would not appear on the organization user list, because that only shows userorganization and those don't exist for the invited users yet. We could change it so it shows both the userorganization and the invites but that seems like a hack.
Another option would be to pre-create the user and mark it as disabled until the user registers and the admin confirms the invite, which to me seems like the best option, but we don't have a disabled flag in the users table and I don't feel like doing an entire migration for that (maybe we can assume that if the masterPasswordHash field is empty that means the user is disabled or something).
@NickBusey commented on GitHub (Jun 29, 2018):
Quick question, how does one disable user registration? I don't see that option in the Readme.
@mprasil commented on GitHub (Jun 29, 2018):
Just set SIGNUPS_ALLOWED environment variable to false.
@mprasil commented on GitHub (Jun 29, 2018):
Apologies, missclicked close.
@dani-garcia commented on GitHub (Jun 29, 2018):
What @mprasil said is correct. You can also modify the
.envfile if you prefer. I've added a short explanation of configuration options to the README in the last commit.@jakob42 commented on GitHub (Jul 10, 2018):
I would love that feature as well, but two things would mitigate the problem in a different fashion for me and might be easier:
Thanks for your work guys!
@mprasil commented on GitHub (Jul 10, 2018):
I like the second option, however there's a caveat that the email address is not verified in any way, so if someone figures out which domain is allowed he can still create basically infinite number of accounts.
I'd imagine, that in many cases this would be okay, but in many other cases it would be easy to guess the domain - like when the domain is well known email provider (gmail for example) or if the domain is same as where your BW server is hosted. It's kind of security by obscurity, but the truth is that it could be easy to implement and often good enough.
@NickBusey commented on GitHub (Jul 10, 2018):
I would say have an array of emails OR email domains.
So I could specify
gmail.comor justuser@gmail.com@ViViDboarder commented on GitHub (Jul 16, 2018):
The idea of creating "disabled" users without a master pw is pretty good. It's a little opaque, but it's easy enough to understand.
This would also make it easier to implement something like LDAP syncing where users can be created automatically and they can set their master pass on first login.
@mprasil commented on GitHub (Sep 11, 2018):
This is now implemented and documented in #173. The docker image with latest code should be built in next two hours.
@ViViDboarder I did the implementation also with your use case in mind, I think you should be able to implement your LDAP sync script. The idea is that you fetch email addresses of all your LDAP users and for those that aren't already registered (in the
userstable) you can insert the email intoinvitationstable. That way said email address can register even withSIGNUPS_ALLOWEDset to false. If you get around to doing that, I'd be interested in your setup, this is something we could add to documentation.