| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
Record how long an access token is valid for, and raise a soft-logout once it
expires.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |
|
|
| |
It's too confusing.
|
| |
|
|
|
|
| |
* Pull config_dir_path and data_dir_path calculation out of read_config_files
* Pass config_dir_path and data_dir_path into read_config
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
When enabling the account validity feature, Synapse will look at startup for registered account without an expiration date, and will set one equals to 'now + validity_period' for them. On large servers, it can mean that a large number of users will have the same expiration date, which means that they will all be sent a renewal email at the same time, which isn't ideal.
In order to mitigate this, this PR allows server admins to define a 'max_delta' so that the expiration date is a random value in the [now + validity_period ; now + validity_period + max_delta] range. This allows renewal emails to be progressively sent over a configured period instead of being sent all in one big batch.
|
| | |
|
| |\
| |
| | |
Send out emails with links to extend an account's validity period
|
| | | |
|
| |\|
| |
| | |
Add time-based account expiration
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it so that most options in the config are optional, and commented out in
the generated config.
The reasons this is a good thing are as follows:
* If we decide that we should change the default for an option, we can do so,
and only those admins that have deliberately chosen to override that option
will be stuck on the old setting.
* It moves us towards a point where we can get rid of the super-surprising
feature of synapse where the default settings for the config come from the
generated yaml.
* It makes setting up a test config for unit testing an order of magnitude
easier (see forthcoming PR).
* It makes the generated config more consistent, and hopefully easier for users
to understand.
|
| |
|
|
|
|
|
|
|
|
| |
* Clarify what registration_shared_secret allows for (#2885)
Signed-off-by: Aaron Raimist <aaron@raim.ist>
* Add changelog
Signed-off-by: Aaron Raimist <aaron@raim.ist>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Rate-limiting for registration
* Add unit test for registration rate limiting
* Add config parameters for rate limiting on auth endpoints
* Doc
* Fix doc of rate limiting function
Co-Authored-By: babolivier <contact@brendanabolivier.com>
* Incorporate review
* Fix config parsing
* Fix linting errors
* Set default config for auth rate limiting
* Fix tests
* Add changelog
* Advance reactor instead of mocked clock
* Move parameters to registration specific config and give them more sensible default values
* Remove unused config options
* Don't mock the rate limiter un MAU tests
* Rename _register_with_store into register_with_store
* Make CI happy
* Remove unused import
* Update sample config
* Fix ratelimiting test for py2
* Add non-guest test
|
| |
|
|
|
|
| |
The general idea here is that config examples should just have a hash and no
extraneous whitespace, both to make it easier for people who don't understand
yaml, and to make the examples stand out from the comments.
|
| |
|
|
|
|
|
| |
If you use double-quotes here, you have to escape your backslashes. It's much
easier with single-quotes.
(Note that the existing double-backslashes are already interpreted by python's
""" parsing.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Sometimes it's useful for synapse to generate its own .well-known file.
|
| |
|
|
| |
configuration (#4207)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* [ ] split config options into allowed_local_3pids and registrations_require_3pid
* [ ] simplify and comment logic for picking registration flows
* [ ] fix docstring and move check_3pid_allowed into a new util module
* [ ] use check_3pid_allowed everywhere
@erikjohnston PTAL
|
| |
|
|
|
| |
lets homeservers specify a whitelist for 3PIDs that users are allowed to associate with.
Typically useful for stopping people from registering with non-work emails
|
| | |
|
| |
|
|
|
| |
New users who register on the server will be dumped into all rooms in
auto_join_rooms in the config.
|
| | |
|
| |
|
|
|
|
|
|
| |
The 'time' caveat on the access tokens was something of a lie, since we weren't
enforcing it; more pertinently its presence stops us ever adding useful time
caveats.
Let's move in the right direction by not lying in our caveats.
|
| |
|
|
|
|
| |
- Add unittests for client, api and handler
Signed-off-by: Negar Fazeli <negar.fazeli@ericsson.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Unfortunately, there are people that are running synapse without a
`macaroon_sercret_key` set. Mandating they set one is a good solution,
except that breaking auto upgrades is annoying.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we store all access tokens in the DB, and fall back to that
check if we can't validate the macaroon, so our fallback works here, but
for guests, their macaroons don't get persisted, so we don't get to
find them in the database. Each restart, we generate a new ephemeral
key, so guests lose access after each server restart.
I tried to fix up the config stuff to be less insane, but gave up, so
instead I bolt on yet another piece of custom one-off insanity.
Also, add some basic tests for config generation and loading.
|
| | |
|
| |
|
|
| |
ID server in integration tests
|
| | |
|
| |
|
|
|
|
|
| |
This follows the same flows-based flow as regular registration, but as
the only implemented flow has no requirements, it auto-succeeds. In the
future, other flows (e.g. captcha) may be required, so clients should
treat this like the regular registration flow choices.
|
| |
|
|
|
| |
By default we leave it at the default value of 12. But now we can reduce
it for preparing users for loadtests or running integration tests.
|
| |
|
|
|
|
|
|
|
|
| |
SYN-287
This requires that HS owners either opt in or out of stats reporting.
When --generate-config is passed, --report-stats must be specified
If an already-generated config is used, and doesn't have the
report_stats key, it is requested to be set.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This just replaces random bytes with macaroons. The macaroons are not
inspected by the client or server.
In particular, they claim to have an expiry time, but nothing verifies
that they have not expired.
Follow-up commits will actually enforce the expiration, and allow for
token refresh.
See https://bit.ly/matrix-auth for more information
|
| | |
|
| |
|
|
| |
default keys
|
| | |
|
| | |
|
| |
|
|
| |
arguments for synapse anticipating that people will use the yaml instead. Simpify implementing config options by not requiring the classes to hit the super class
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
for registration to be disabled by default now. this is backwards incompatible by removing the old --disable-registration arg, but makes for a much more intuitive arg
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
