-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Room version 8 and 9 support #279
Conversation
// 'join_authorised_via_users_server' key, containing the user ID of a user | ||
// in the room that should have a suitable power level to issue invites. | ||
// If no such key is specified then we should reject the join. | ||
if _, _, err := SplitID('@', m.newMember.AuthorisedVia); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's stopping servers from lying about who authorised this? Can I not just be malicious and guess that "hey Alice is probably in $secret_room, let's slap an authorised key as alice and I can get in"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the authorising server has to have signed the event as well. I assume the malicious person could enter a different user ID from the same signing server, but unless that user has the power levels to invite, I don't suppose it'd help them at all.
In theory, this PR adds support for room version 8 and 9.