Currently, when a 3pid invite request is sent to an identity server, it
includes a provisioned guest access token. This allows the link in the,
say, invite email to include the guest access token ensuring that the
same account is used each time the link is clicked.
This flow has a number of flaws, including when using different servers
or servers that have guest access disabled.
For now, we keep this implementation but hide it behind a config option
until a better flow is implemented.
This means that following the same link across multiple sessions or
devices can re-use the same guest account.
Note that this is somewhat of an abuse vector; we can't throw up
captchas on this flow, so this is a way of registering ephemeral
accounts for spam, whose sign-up we don't rate limit.
Currently, we magically perform an extra database hit to find the
inviter, and use this to guess where we should send the event. Instead,
fill in a valid context, so that other callers relying on the context
actually have one.
Force joining by alias to go through the send_membership_event checks,
rather than bypassing them straight into _do_join. This is the first of
many stages of cleanup.
There's at least one more to merge in.
Side-effects:
* Stop reporting None as displayname and avatar_url in some cases
* Joining a room by alias populates guest-ness in join event
* Remove unspec'd PUT version of /join/<room_id_or_alias> which has not
been called on matrix.org according to logs
* Stop recording access_token_id on /join/room_id - currently we don't
record it on /join/room_alias; I can try to thread it through at some
point.
Erroring causes problems when people make illegal requests, because they
don't know what limit parameter they should pass.
This is definitely buggy. It leaks message counts for rooms people don't
have permission to see, via tokens. But apparently we already
consciously decided to allow that as a team, so this preserves that
behaviour.
Erroring causes problems when people make illegal requests, because they
don't know what limit parameter they should pass.
This is definitely buggy. It leaks message counts for rooms people don't
have permission to see, via tokens. But apparently we already
consciously decided to allow that as a team, so this preserves that
behaviour.
