See the response from @david above:
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.
Yes I saw that. Noted.
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).
2 Likes
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.
1 Like
Don’t forget that bulk invites are also an option here, if your event generates a csv of attendees you can use this to invite everyone directly.
If not then you can also share a url to a web form to populate a CSV and validate users there prior to sending the bulk invite.
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).
1 Like
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.
1 Like
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.
2 Likes
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_usersis 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?
1 Like
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”.
2 Likes
This is certainly what we should do. We will get this fixed over the next few days.
8 Likes
Since the issue here was a staff member sending a multi use invite to a single person, you could keep the old behavior by disabling auto approve for any multiple use invites while keeping it for single use.
Additionally, the education (“this user will be approved when they accept the invitation”) (now only for single use invites) should go on the invite dialog, not the site settings page.
1 Like
I am afraid I am making the very hard line call here that must_approve_users == VERY HARD LINE definition of explicit approval must be given.
The trouble with implicit approval (which I originally approved) is that it is full of edge cases. Edge cases breed security problems and flaws in the system. Additionally, explaining edge cases regarding implicit approval is way too complicated and not a headache we need.
If you go for must_approve_users we will take the absolute strictest definition and require you explicitly click approve on every single account regardless of invite vs not invite.
8 Likes
Just to clarify, the invite link was sent to a meeting chat room, i.e. a bunch of people that were authorized to join, and not to a single person. We set max use to the number of people in that chat room. One of them then forwarded the link to someone else belonging to an unauthorized entity, who used it faster than the people in the chat room.
3 Likes
3 Likes
Great! My sys admin takes care of updating the instance. He only updates from your beta releases when a new one shows up here:
Will it make it there eventually? If so, when could that happen?
[Edit] I see a new one here:
Is it that one?
1 Like
Yes, you want to hit that one and then when it is complete return to upgrade everything else using the upgrade all button. You have to upgrade docker first, and separately, unless you are upgrading from the command line.
3 Likes
Sam, many thanks for addressing this issue. It will take a few days before my sys admin updates things.
3 Likes
Not probs!
All thanks should go to @tgxworld / @martin / @gerhard , it is a surprisingly complex change
4 Likes
This topic was automatically closed after 7 days. New replies are no longer allowed.