allow_registration=false don't forbid guests, thus registration_token don't forbid the first guest to become admin #415
Labels
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Matthias/conduit#415
Loading…
Reference in a new issue
No description provided.
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?
Headline
How to forbid first guest to become admin instead of first registered user?
Description
I set up conduit.toml like that
and thus, if I was not fast enough, I would not become admin, an other "user" would become admin even though the TOKEN was pretty strong.
Then, I realized that if I open a new private window in Firefox and I go directly to https://MYDOMAIN/element/#/home , then it would log me as a guest.
Finally I tried reintalling conduit with the same conduit.toml and to log as a guest as fast as possible going to https://MYDOMAIN/element/#/home and indeed, my guest join the admin room and became admin.
So I guess, conduit needs an other setting such as
allow_guets = false
to forbid guests to join the server when we don't want to.changed title from allow_registration=false don't forbid {-visitor-}s, registration_token don't forbid first {-visitor-} to become admin to allow_registration=false don't forbid {+guest+}s, registration_token don't forbid first {+guets+} to become admin
changed the description
I had a thought about an allow_guests option.
I think it should not be true/false only because the main reason we want guests to connect to a room is by invitation.
So I'd suggest something like
I even wonder if there is a use case for disabled if "on invitation" option exists.
Setting "on invitation" option by default at install time would solve the problem of the first guest becoming admin if a user is not created fast enough. Indeed, no guest could connect before a first user is created and invite them.
changed title from allow_registration=false don't forbid guests{-,-} registration_token don't forbid first guets to become admin to allow_registration=false don't forbid guests{+ thus+} registration_token don't forbid first guets to become admin
changed title from allow_registration=false don't forbid guests thus registration_token don't forbid first guet{-s-} to become admin to allow_registration=false don't forbid guests thus registration_token don't forbid {+the +}first guet to become admin
Finally, the bigger question is about how Conduit should handle guets. SO far, it simply accept all guests whatsoever.
I think that should be an option to activate for advance user. The default option should be to accept guests who have been invited and join a (specific) room thanks to a specific URL (Token). Guests should not be able to create rooms.
What do you think?
I agree that guests shouldn't be able to create rooms. I would also welcome an option for disabling guests.
On the other hand, I really don't think there's much attack surface here - if somebody sets up a server, and somebody else is faster in creating an account on the server than the person who set it up, then the server admin would see that pretty quickly and nuke it, I suppose.
Well someone who install Conduit for the first time, might not be surprised not to find the admin room and won't wonder about it.
changed title from allow_registration=false don't forbid guests thus registration_token don't forbid the first guet to become admin to allow_registration=false don't forbid guests{+,+} thus registration_token don't forbid the first gue{+s+}t to become admin
changed the description