We’ve had a serious security issue with the invite system. I guess it’s easily reproducible. Our site is on invite-only. In addition, we have checked “must approve users” in the settings.
One of our staff issued an invitation with a max use greater than 1, thus not restricted to one email in particular (example below).
That invite link circulated, and people could register with it. Yet we expected that when “must approve users” is checked in the settings, then staff would have to approve anyone using those “email-unrestricted” invitation. Instead, they were all let in automatically, whomever had that link. So the link can be used by just anyone and we cannot check who gets in with it. We must be able to “background check”, using the combination of the email, name, and other fields we added, which are mandatory fields we ask to get approved (after we check).
This created a serious issue as someone from a strictly forbidden foreign organization got that link and did register. I had to delete that account right away. That’s a serious loophole for us.
So I find the “must approve users” dangerously misleading. Currently that option is moot if we are on an invite-only instance.
Is there a way to have the staff be able to approve someone using the invite link that hasn’t been email-restricted? That would seem to be a logical way of having the “must approve users” enabled when the site is invite-only.
I can reproduce the issue, when a bulk invite is generated, the users signing up with that link are automatically immune to the must approve users setting.
The key thing here is that a staff member issued the invitation. Discourse treats that as an implicit approval of the users which make use of the invitation
If a non-staff member generated the invitation, then the redeeming user would be added to the queue for staff to approve.
so if a non-staff user account is used to create an invite then it would put the signups through that invite in review queue? If that’s the case, it is totally acceptable behavior & @Wall-E you could use a dummy regular account to generate the invite as a workaround.
I think there should at least be a warning for staff users, and it would be fantastic if they could get to choose how the new members will be treated. Using a second, “normal”, user would be an ugly workaround.
Reading through this topic and the previous topics, I can see that the current functioning is “by design” but does not reflect the new changes to the invite system. It has become much easier to create invite links that can be used by unknown people. Invite links now also dangerously can be created by staff that add invitees to groups that can have access to secure categories on the site.
@Wall-E I am curious to understand how it is that your invite links are falling into the hands of people who should not be allowed access to your site. Presumably your site’s staff will know to be careful not to create invite links that can be used by anyone and share them publicly or in settings where the wrong people will be able to use them. To some extent the issue you are facing is a staff training issue. Feel free to PM me your answer if it contains specifics that are sensitive.
If there are invite links existing currently that are somehow compromised, you can delete them and create new ones and share them more carefully in the future. As admin, you can also always look on the invites page for the user to see who has redeemed their invites. If you have staff you do not trust, you can lower their privs to TL4 which has near moderator privileges.
I see three possible courses of action:
Do nothing. Invite system is working as designed, staff just need to be careful with their invite links. If we take this route, suggest we change description of must approve users admin setting to make it crystal clear that invite links created by admins bypass this setting.
Staff must approve all new user accounts before they are allowed to access the site. Note: invites created by staff bypass this setting and do not require approval.
Do (1) but also add an extra “are you sure” warning step when admins create an invite link that can be used to immediately gain access to the site. Only on sites with approval required.
Change behavior so invite links created by admins respect the approval required setting just like invites by non-admins.
I agree with the OP that the current behavior is misleading, and has the potential to lead to problems on sites when approval is required. Sites with this setting enabled are extra cautious and need this extra paranoid level of control over who can gain access.
My recommendation therefore would be for us to choose door number three - make all invite links work the same way and respect the must approve users setting.
I don’t think this is a bug, however. It’s working as designed. Reclassifying as feature request.
I am also strongly in favor of option 3. I’m building a community where people may reflect more deeply on emotions and I think adding that extra level of gating on the anonymous invite links (because they’re not tied to an email address or identity) could make me feel more at ease that only the people I want to join will do so.
I suppose I could make sure to use the invite email instead of anonymous invite link, but the link makes it so much easier to share in Whatsapp or other communication platforms.
So I’m also in favor of making the anonymous invite links respect the must approve users setting.
Also, I think if #3 happens, then the invite system can function almost as an application system for invite-only forums. Right now, I’m not sure how I would have people apply to be a member without having a separate Google Form or such. This could streamline it in a way, where custom user fields could be the application form—which is what I think @Wall-E is trying to do.
That’s not what my topic is about. I am talking about the must_approve_users having no effect in an invite-only instance. Turning it on should have a different effect than turning it on. If not, then it should be documented that this behavior does not apply to invite-only instance. If I missed it in the documentation, then it is indeed our staff’s responsibility. But if it is not, then that feature is misleading, and should either be fixed, or at least documented), as it has misled all of our staff.
Absolutely. I could have missed in the documentation, if it was documented, then it would be my responsbility to have misled my staff, and a warning won’t hurt, because people/staff can forget.
I am going to quote the powers that be who can shut us down due to that aspect, which is considered a security issue in our organization: " If this system can allow someone from an unauthorized organization to get in, you have to assume it eventually will, regardless of your diligence". This is exactly what happened. That “feature” (i’d say, a non-feature as the “must_approve_user” has just no effect in the invite-only case) was enabled, we issued the unrestricted invitation to the very people we wanted to invite, and obviously, one of these people shared that unrestricted invitation link with another organization.
With this I’m also answering @tobiaseigen
We have meetings, conferences, with sometimes hundreds of people from authorized organizations that are allowed to join our forum. But some of them are sometimes from other organizations that are not authorized to join our forum (due to overarching policies not under our control).
That invitation link ran “loose”, even with the staff’s diligence, as we cannot control what the “implicitly authorized” people with that link will do; by definition, that link is “unrestricted”, so they can forward it to anyone they want. I cannot blame my staff for that, as if you say it is “by design” there is an implicit approval, it means that this unresticted invite link can make it anywhere, thus it eventually will. This is exactly what our IT department heads was talking about, for good reasons. We knew that, and so we enabled the *must_approve_users" to act as that security layer that we thought it was for.
I see there’s a question on whether this is a feature or a bug. I’m not a professional programmer, that’s for you to decide (I’m an astrophysicist). I’m merely reporting to you a serious “issue” it caused us, hoping it can be addressed so we can continue using this wonderful platform.
I am fully in favor of option 3, so is our research center, and my forum’s staff. Until further notice, the staff is instructed not to use the unrestricted invite. Which adds extra burden as they now have to add all individual email addresses of people we want to invite (and at a conference, that’s more than hundreds of participants…). Doing it at each meeting, events, etc… will add high viscosity to our growth, and I can foresee some staff member leaving due to the added workload (most of them are volunteers, and all overworked with their other duties).
Is it safe to assume that if option 3 goes ahead there will be some option to match the existing behavior?
The training site we threw together would have been far harder to execute without the ability to bypass approvals for the groups who were invited en-masse.
Unfortunately our typical events don’t give us access to that. Those contact lists are treated as PII (Personally Identifiable Information) by the host organization hosting the conference/meeting. Even if we had access, we just don’t have the bandwidth to use that feature. We’d have to get in touch to a POC, who is always overworked (even if we are allowed to have access to the info), so again, high viscosity, by the time we get the invite links, the event is over, the momentum is lost (by our staff, and by our potential invitees).
Noted. That could be a workaround. But that is added workload to our staff, who doesn’t have much the bandwidth for processing that extra step. So, that’s not ideal.
I can see this caused some problems for you and your community, and I’m sorry about that!
Going forward, now you know how it works so you can be sure that you and fellow admins and moderators will use the invite system judiciously!
The feature vs bug question is about prioritization - we try to fix bugs quickly, especially if they are security bugs! But in this case the functionality is the same as it’s been for years and it is this way by design. I think we should change it but it’s not a drop everything and fix it now kinda thing.
We’ll give this some time for others to weigh in so we can decide the direction we’d like to go.
It may be a much more complex change depending on how the guardian is involved in the different elements of this process but another option, which would also depend on 3, is:
Add a boolean property to the invites themselves for bypassing user approval. This property would be default off and only exposed in the create invite UI when must_approve_users is enabled
Edit: Actually looking again at the code David referenced, I guess the guardian isn’t involved at all in deciding whether an invited user needs to be approved. It looks like that part of it would be a straightforward replacement of invite.invited_by.staff? with something like invite.bypass_approval?
I completely understand your constraints of prioritization. I guess our instance is in an uncommon situation, as all the discourse instances I know are from organizations that don’t have the tight security policies by which we have to abide. E.g., invite-only was a constraint that was imposed by our organization, our instance could not exist with self-signup. With a self-signup, it would be easier, we would not need to use the unrestricted invitations that can get “loose”.
