| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |\
| | | |
| | | |
| | | | |
erikj/admin_exfiltrate_data
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | | |
Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
| | | | |
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | | |
Record how long an access token is valid for, and raise a soft-logout once it
expires.
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
this is only used in one place, so it's clearer if we inline it and reduce the
API surface.
Also, fixes a buglet where we would create an access token even if we were
about to block the user (we would never return the AT, so the user could never
use it, but it was still created and added to the db.)
|
|\| | | |
|
| |\ \ \
| | | | |
| | | | | |
Send 3PID bind requests as JSON data
|
| | | | | |
|
| | | | | |
|
|\| | | | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
The 'token' param is no longer used anywhere except the tests, so let's kill
that off too.
|
|\| | | |
|
| |\ \ \
| | | | |
| | | | | |
Use JSON when querying the IS's /store-invite endpoint
|
| | |\ \ \ |
|
| | | | | | |
|
| | | | | | |
|
|\| | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
FederationDeniedError is a subclass of SynapseError, which is a subclass of
CodeMessageException, so if e is a FederationDeniedError, then this check for
FederationDeniedError will never be reached since it will be caught by the
check for CodeMessageException above. The check for CodeMessageException does
almost the same thing as this check (since FederationDeniedError initialises
with code=403 and msg="Federation denied with %s."), so may as well just keep
allowing it to handle this case.
|
|\| | | | | |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
Allow newly-registered users to lookup their own profiles
|
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | | |
When a user creates an account and the 'require_auth_for_profile_requests' config flag is set, and a client that performed the registration wants to lookup the newly-created profile, the request will be denied because the user doesn't share a room with themselves yet.
|
|\| | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Nothing uses this now, so we can remove the dead code, and clean up the
API.
Since we're changing the shape of the return value anyway, we take the
opportunity to give the method a better name.
|
|\| | | | | |
|
| |/ / / /
| | | | |
| | | | | |
It was pretty unclear what was going on, so I've added a couple of log lines.
|
| | | | |
| | | | |
| | | | | |
This is only used in tests, so...
|
|\| | | | |
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This has never been documented, and I'm not sure it's ever been used outside
sytest.
It's quite a lot of poorly-maintained code, so I'd like to get rid of it.
For now I haven't removed the database table; I suggest we leave that for a
future clearout.
|
| | | | |
|
| | | | |
|
| | | | |
|
|\| | | |
|
| | | | |
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | | |
Fixes #5602, #5603
|
|\| | | |
|
| |\ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* SAML2 Improvements and redirect stuff
Signed-off-by: Alexander Trost <galexrt@googlemail.com>
* Code cleanups and simplifications.
Also: share the saml client between redirect and response handlers.
* changelog
* Revert redundant changes to static js
* Move all the saml stuff out to a centralised handler
* Add support for tracking SAML2 sessions.
This allows us to correctly handle `allow_unsolicited: False`.
* update sample config
* cleanups
* update sample config
* rename BaseSSORedirectServlet for consistency
* Address review comments
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
This allows us to correctly handle `allow_unsolicited: False`.
|
| | | |/
| | |/| |
|
|\| | | |
|
| |\ \ \
| | |_|/
| |/| | |
Fix sync tightloop bug.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If, for some reason, presence updates take a while to persist then it
can trigger clients to tightloop calling `/sync` due to the presence
handler returning updates but not advancing the stream token.
Fixes #5503.
|
| |\ \ \
| | | | |
| | | | | |
Don't update the ratelimiter before sending a 3PID invite
|
| | | | |
| | | | |
| | | | |
| | | | | |
If we do the opposite, an event can arrive after or while sending the email and the 3PID invite event will get ratelimited.
|
| | | |/
| | |/|
| | | |
| | | | |
This would cause emails being sent, but Synapse responding with a 429 when creating the event. The client would then retry, and with bad timing the same scenario would happen again. Some testing I did ended up sending me 10 emails for one single invite because of this.
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Daniel Hoffend <dh@dotlan.net>
|
|\| | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a client asks for users whose devices have changed since a token we
used to pull *all* users from the database since the token, which could
easily be thousands of rows for old tokens.
This PR changes this to only check for changes for users the client is
actually interested in.
Fixes #5553
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Closes #4583
Does slightly less than #5045, which prevented a room from being upgraded multiple times, one after another. This PR still allows that, but just prevents two from happening at the same time.
Mostly just to mitigate the fact that servers are slow and it can take a moment for the room upgrade to actually complete. We don't want people sending another request to upgrade the room when really they just thought the first didn't go through.
|
|\| | |
|
| |\ \
| | | |
| | | | |
Fix /messages on workers when no from param specified.
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | | |
If no `from` param is specified we calculate and use the "current
token" that inlcuded typing, presence, etc. These are unused during
pagination and are not available on workers, so we simply don't
calculate them.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | | |
Because sticking it in the same place as the config isn't necessarily the right
thing to do.
|
|\| | |
|
| |/
| |
| | |
This makes some of the conditional-import hoop-jumping easier.
|
|\| |
|
| | |
|
| |\
| | |
| | | |
Handle the case of `get_missing_events` failing
|
| | | |
|
|\| | |
|
| |\ \
| | | |
| | | | |
Add experimental option to reduce extremities.
|
| | | | |
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I had to add quite a lot of logging to diagnose a problem with 3pid
invites - we only logged the one failure which isn't all that
informative.
NB. I'm not convinced the logic of this loop is right: I think it
should just accept a single valid signature from a trusted source
rather than fail if *any* signature is invalid. Also it should
probably not skip the rest of middle loop if a check fails? However,
I'm deliberately not changing the logic here.
|
|\ \ \ \
| | |_|/
| |/| | |
|
| | | | |
|
|\| | |
| | | |
| | | |
| | | | |
erikj/fix_get_missing_events_error
|
| |\| |
| | | |
| | | |
| | | | |
erikj/fix_get_missing_events_error
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Currently if a call to `/get_missing_events` fails we log an exception
and stop processing the top level event we received over federation.
Instead let's try and handle it sensibly given it is a somewhat expected
failure mode.
|
|\ \ \ \
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Adds new config option `cleanup_extremities_with_dummy_events` which
periodically sends dummy events to rooms with more than 10 extremities.
THIS IS REALLY EXPERIMENTAL.
|
|\ \ \ \
| | |_|/
| |/| | |
|
| | | | |
|
| |/ / |
|
|\| | |
|
| |\ \
| | | |
| | | | |
Handle HttpResponseException when using federation client.
|
| | | |
| | | |
| | | |
| | | | |
Otherwise we just log exceptions everywhere.
|
| |\ \ \
| | | | |
| | | | | |
Fix 3PID invite room state over federation.
|
| |\ \ \ \
| | | | | |
| | | | | | |
Allow server admins to define implementations of extra rules for allowing or denying incoming events
|
|\ \ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Purge jobs don't delete the latest event in a room in order to keep the forward extremity and not break the room. On the other hand, get_state_events, when given an at_token argument calls filter_events_for_client to know if the user can see the event that matches that (sync) token. That function uses the retention policies of the events it's given to filter out those that are too old from a client's view.
Some clients, such as Riot, when loading a room, request the list of members for the latest sync token it knows about, and get confused to the point of refusing to send any message if the server tells it that it can't get that information. This can happen very easily with the message retention feature turned on and a room with low activity so that the last event sent becomes too old according to the room's retention policy.
An easy and clean fix for that issue is to discard the room's retention policies when retrieving state.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The `http_proxy` and `HTTPS_PROXY` env vars can be set to a `host[:port]` value which should point to a proxy.
The address of the proxy should be excluded from IP blacklists such as the `url_preview_ip_range_blacklist`.
The proxy will then be used for
* push
* url previews
* phone-home stats
* recaptcha validation
* CAS auth validation
It will *not* be used for:
* Application Services
* Identity servers
* Outbound federation
* In worker configurations, connections from workers to masters
Fixes #4198.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
While this is not documented in the spec (but should be), Riot (and other clients) revoke 3PID invites by sending a m.room.third_party_invite event with an empty ({}) content to the room's state.
When the invited 3PID gets associated with a MXID, the identity server (which doesn't know about revocations) sends down to the MXID's homeserver all of the undelivered invites it has for this 3PID. The homeserver then tries to talk to the inviting homeserver in order to exchange these invite for m.room.member events.
When one of the invite is revoked, the inviting homeserver responds with a 500 error because it tries to extract a 'display_name' property from the content, which is empty. This might cause the invited server to consider that the server is down and not try to exchange other, valid invites (or at least delay it).
This fix handles the case of revoked invites by avoiding trying to fetch a 'display_name' from the original invite's content, and letting the m.room.member event fail the auth rules (because, since the original invite's content is empty, it doesn't have public keys), which results in sending a 403 with the correct error message to the invited server.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | | |
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
|
| | | | | | |
| | | | | | |
| | | | | | | |
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
|
| | | | | | | |
|
|\| | | | | |
| |/ / / / /
|/| | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \ |
|
| | | | | | | |
|
|/ / / / / / |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Port #5644 to dinsic
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When a user creates an account and the 'require_auth_for_profile_requests' config flag is set, and a client that performed the registration wants to lookup the newly-created profile, the request will be denied because the user doesn't share a room with themselves yet.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If we do the opposite, an event can arrive after or while sending the email and the 3PID invite event will get ratelimited.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
This would cause emails being sent, but Synapse responding with a 429 when creating the event. The client would then retry, and with bad timing the same scenario would happen again. Some testing I did ended up sending me 10 emails for one single invite because of this.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix new 3PID bindings being associated with rewritten IS's server names instead of the original one
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
instead of the original one
This would make unbind requests fail because Synapse is using the server name it has in DB as destination_is to generate signature, and Sydent uses its own server name there when verifying it, so if a mismatch happens, which is the case if the name gets rewritten for routing purposes, the unbind requests fail on the signature verification.
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | |_|_|/ / /
| |/| | | | | |
Port "Fix 3PID invite room state over federation" to dinsic
|
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes that when a user exchanges a 3PID invite for a proper invite over
federation it does not include the `invite_room_state` key.
This was due to synapse incorrectly sending out two invite requests.
|
|\ \ \ \ \ \
| | |_|/ / /
| |/| | | | |
|
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \ |
|
| |\| | | | |
|
| | | |/ /
| | |/| | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
identity server (#5377)
Sends password reset emails from the homeserver instead of proxying to the identity server. This is now the default behaviour for security reasons. If you wish to continue proxying password reset requests to the identity server you must now enable the email.trust_identity_server_for_password_resets option.
This PR is a culmination of 3 smaller PRs which have each been separately reviewed:
* #5308
* #5345
* #5368
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes some warnings, and a scary-looking stacktrace when sytest kills the
process.
|
| | |\ \ \
| | | | | |
| | | | | | |
Make /sync return heroes if room name or canonical alias are empty
|
| | | | | | |
|
| | | | | | |
|
| | | |\ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I probably should've just run autopep8 in the first place...
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes #4194
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes #4194
Signed-off-by: Katie Wolfe <katie@dnaf.moe>
|
| | |\ \ \ \ \
| | | | | | | |
| | | | | | | | |
Include left members in room summaries' heroes
|
| | | | |/ / /
| | | |/| | |
| | | | | | |
| | | | | | | |
the joined members or the parted ones
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* Fix background updates to handle redactions/rejections
In background updates based on current state delta stream we need to
handle that we may not have all the events (or at least that
`get_events` may raise an exception).
|
| | | | | | | |
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When processing an incoming event over federation, we may try and
resolve any unexpected differences in auth events. This is a
non-essential process and so should not stop the processing of the event
if it fails (e.g. due to the remote disappearing or not implementing the
necessary endpoints).
Fixes #3330
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
Limit displaynames and avatar URLs
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These end up in join events everywhere, so let's limit them.
Fixes #5079
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes #4414.
|
| | |\ \ \ \ \
| | | | | | | |
| | | | | | | | |
Don't bundle aggregations with events in /sync or /events or state queries
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
As we'll send down the annotations too anyway, so this just ends up
confusing clients.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Replaces DEFAULT_ROOM_VERSION constant with a method that first checks the config, then returns a hardcoded value if the option is not present.
That hardcoded value is now located in the server.py config file.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
I was staring at this function trying to figure out wtf it was actually
doing. This is (hopefully) a non-functional refactor which makes it a bit
clearer.
|
| | | |/ / / /
| | |/| | | | |
|
| |\| | | | |
| | |_|_|/ /
| |/| | | | |
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
Block attempts to annotate the same event twice
|
| | | | | | | |
|
| | | |/ / / |
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When considering the candidates to be forward-extremities, we must exclude soft
failures.
Hopefully fixes #5090.
|
| | | | | |
|
| | | | |
| | | | |
| | | | | |
* fix mapping of return values for get_or_register_3pid_guest
|
| | | | | |
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | | |
Allow server admins to define and enforce a password policy (MSC2000)
|
| | | | | |
|
| |/ / / |
|
|\| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
users (#3484)
|
| | | | |
|
| | | | |
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
CS API (#5083)
This commit adds two config options:
* `restrict_public_rooms_to_local_users`
Requires auth to fetch the public rooms directory through the CS API and disables fetching it through the federation API.
* `require_auth_for_profile_requests`
When set to `true`, requires that requests to `/profile` over the CS API are authenticated, and only returns the user's profile if the requester shares a room with the profile's owner, as per MSC1301.
MSC1301 also specifies a behaviour for federation (only returning the profile if the server asking for it shares a room with the profile's owner), but that's currently really non-trivial to do in a not too expensive way. Next step is writing down a MSC that allows a HS to specify which user sent the profile query. In this implementation, Synapse won't send a profile query over federation if it doesn't believe it already shares a room with the profile's owner, though.
Groups have been intentionally omitted from this commit.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Follow-up to #5124
Also added a bunch of checks to make sure everything (both the stuff added on #5124 and this PR) works as intended.
|
| |\ \ \
| | | | |
| | | | | |
Ratelimit 3pid invites
|
| | | | | |
|
| | |\ \ \
| | | | | |
| | | | | |
| | | | | | |
erikj/ratelimit_3pid_invite
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We do ratelimit sending the 3PID invite events, but that happens after
spamming the identity server.
|
| | |/ / /
| |/| | | |
|
| | |/ /
| |/| |
| | | |
| | | | |
Fixes #5102
|
| |\ \ \
| | | | |
| | | | |
| | | | | |
babolivier/account_expiration
|
| | |\ \ \
| | | |_|/
| | |/| | |
Send out emails with links to extend an account's validity period
|
| | |/ /
| |/| | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | | |
Co-Authored-By: babolivier <contact@brendanabolivier.com>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(#5061)
Co-Authored-By: babolivier <contact@brendanabolivier.com>
|
|\ \ \ \
| | |/ /
| |/| | |
|
| | |/
| |/| |
|
| | |
| | |
| | | |
Prevent kick events from succeeding if the user is not currently in the room.
|
| | | |
|
| | |
| | |
| | | |
Remove presence list support as per MSC 1819
|
| |\ \
| | | |
| | | | |
Implement MSC1915 - 3PID unbind APIs
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By default the homeserver will use the identity server used during the
binding of the 3PID to unbind the 3PID. However, we need to allow
clients to explicitly ask the homeserver to unbind via a particular
identity server, for the case where the 3PID was bound out of band from
the homeserver.
Implements MSC915.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This changes the behaviour from using the server specified trusted
identity server to using the IS that used during the binding of the
3PID, if known.
This is the behaviour specified by MSC1915.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This will then be used to know which IS to default to when unbinding the
threepid.
|
| | | |
| | | |
| | | | |
Transfers the m.room.related_groups state event on room upgrade.
|
| |/ /
| | |
| | |
| | | |
Collect all the things that make room-versions different to one another into
one place, so that it's easier to define new room versions.
|
| | |
| | |
| | | |
This PR allows password provider modules to bind email addresses when a user is registering and is motivated by matrix-org/matrix-synapse-ldap3#58
|
| | | |
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Primarily this fixes a bug in the handling of remote users joining a
room where the server sent out the presence for all local users in the
room to all servers in the room.
We also change to using the state delta stream, rather than the
distributor, as it will make it easier to split processing out of the
master process (as well as being more flexible).
Finally, when sending presence states to newly joined servers we filter
out old presence states to reduce the number sent. Initially we filter
out states that are offline and have a last active more than a week ago,
though this can be changed down the line.
Fixes #3962
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
Adds a new method, check_3pid_auth, which gives password providers
the chance to allow authentication with third-party identifiers such
as email or msisdn.
|
| | |
|
| |\
| | |
| | | |
Deny peeking into rooms that have been blocked
|
| | | |
|
| | |
| | |
| | | |
* Rewrite more internal IS urls.
|
| | | |
|
| | |
| | |
| | |
| | | |
We also add an option to outright deny third party invites
|
|\| | |
|
| |\|
| | |
| | | |
Fixup shutdown room API
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are a number of instances where a server or admin may puppet a
user to join/leave rooms, which we don't want to fail if the user has
not consented to the privacy policy. We fix this by adding a check to
test if the requester has an associated access_token, which is used as a
proxy to answer the question of whether the action is being done on
behalf of a real request from the user.
|
| |\ \
| | |/
| |/| |
Add option to disable search room lists
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This disables both local and remote room list searching.
|
| |/
| |
| |
| | |
Rate-limit outgoing read-receipts as per #4730.
|
| | |
|
| | |
|
| | |
|
| |
| |
| | |
Add two ratelimiters on login (per-IP address and per-userID).
|
| |\
| | |
| | | |
Move client receipt processing to federation sender worker.
|
| | |
| | |
| | |
| | |
| | | |
This is mostly a prerequisite for #4730, but also fits with the general theme
of "move everything off the master that we possibly can".
|
| | |
| | |
| | |
| | |
| | | |
I'm going to use this in queues and things, so it'll be useful to give it more
of a structure.
|
| |\ \
| | |/
| |/| |
Improve searching in the userdir
|
| | | |
|
| | | |
|