summary refs log tree commit diff
path: root/synapse/config/registration.py (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Don't load the generated config as the default.Richard van der Hoff2019-06-241-1/+1
| | | | It's too confusing.
* Pass config_dir_path and data_dir_path into Config.read_config. (#5522)Richard van der Hoff2019-06-241-1/+1
| | | | | | * 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
* Run Black. (#5482)Amber Brown2019-06-201-19/+22
|
* Move delta from +10% to -10%Brendan Abolivier2019-05-311-1/+1
|
* Gah pythonBrendan Abolivier2019-05-311-1/+1
|
* Make max_delta equal to period * 10%Brendan Abolivier2019-05-311-11/+4
|
* Allow configuring a range for the account validity startup jobBrendan Abolivier2019-05-281-0/+11
| | | | | 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.
* DocBrendan Abolivier2019-05-211-0/+8
|
* Merge pull request #5047 from matrix-org/babolivier/account_expirationBrendan Abolivier2019-04-171-8/+44
|\ | | | | Send out emails with links to extend an account's validity period
| * Send out emails with links to extend an account's validity periodBrendan Abolivier2019-04-171-8/+44
| |
* | Merge pull request #5027 from matrix-org/babolivier/account_expirationBrendan Abolivier2019-04-091-0/+17
|\| | | | | Add time-based account expiration
| * Add account expiration featureBrendan Abolivier2019-04-091-0/+17
| |
* | Add config option to block users from looking up 3PIDs (#5010)Brendan Abolivier2019-04-041-0/+5
|/
* Comment out most options in the generated config. (#4863)Richard van der Hoff2019-03-191-10/+15
| | | | | | | | | | | | | | | | | | | | 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) (#4844)Aaron Raimist2019-03-111-2/+2
| | | | | | | | | | * 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>
* Move settings from registration to ratelimiting in config fileBrendan Abolivier2019-03-051-18/+2
|
* Add rate-limiting on registration (#4735)Brendan Abolivier2019-03-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Attempt to make default config more consistentRichard van der Hoff2019-02-191-15/+21
| | | | | | 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.
* Fix quoting for allowed_local_3pids example config (#4476)Richard van der Hoff2019-01-251-3/+3
| | | | | | | 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.)
* fix line lengthNeil Johnson2019-01-211-1/+3
|
* Config option to disable requesting MSISDN on registrationNeil Johnson2019-01-211-0/+7
|
* Add a script to generate a clean config file (#4315)Richard van der Hoff2018-12-221-3/+8
|
* Implement .well-known handling (#4262)Richard van der Hoff2018-12-051-0/+9
| | | | Sometimes it's useful for synapse to generate its own .well-known file.
* Remove riot.im from the list of trusted Identity Servers in the default ↵Neil Johnson2018-11-201-1/+3
| | | | configuration (#4207)
* isortNeil Johnson2018-10-241-2/+1
|
* remove errant exception and styleNeil Johnson2018-10-231-1/+1
|
* clean up config error logic and importsNeil Johnson2018-10-171-5/+4
|
* improve auto room join logic, comments and testsNeil Johnson2018-10-121-1/+10
|
* fix UTsMatthew Hodgson2018-09-281-1/+1
|
* untested stab at autocreating autojoin roomsMatthew Hodgson2018-09-281-0/+4
|
* run isortAmber Brown2018-07-091-2/+2
|
* spell out not to massively increase bcrypt roundsMatthew Hodgson2018-03-191-1/+3
|
* rewrite based on PR feedback:Matthew Hodgson2018-01-191-3/+9
| | | | | | | | | * [ ] 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
* add registrations_require_3pidMatthew Hodgson2018-01-191-0/+13
| | | | | 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
* pep8David Baker2017-10-171-1/+2
|
* Add config option to auto-join new users to roomsDavid Baker2017-10-161-0/+6
| | | | | New users who register on the server will be dumped into all rooms in auto_join_rooms in the config.
* trust a hypothetical future riot.im ISMatthew Hodgson2017-04-101-0/+1
|
* Stop putting a time caveat on access tokensRichard van der Hoff2016-11-291-6/+0
| | | | | | | | 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.
* Create user with expiryNegi Fazeli2016-05-131-0/+6
| | | | | | - Add unittests for client, api and handler Signed-off-by: Negar Fazeli <negar.fazeli@ericsson.com>
* Add config to create guest account on 3pid inviteErik Johnston2016-03-141-0/+4
| | | | | | | | | | | | | 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.
* Derive macaroon_secret_key from signing key.Erik Johnston2016-02-081-15/+3
| | | | | | 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.
* Error if macaroon key is missing from configDaniel Wagner-Hall2016-02-051-4/+14
| | | | | | | | | | | | | 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.
* Rename config field to reflect yaml nameDaniel Wagner-Hall2016-02-031-3/+3
|
* Add config option for setting the trusted id servers, disabling checking the ↵Mark Haines2016-01-291-0/+7
| | | | ID server in integration tests
* copyrightsMatthew Hodgson2016-01-071-1/+1
|
* Allow guests to register and call /events?room_id=Daniel Wagner-Hall2015-11-041-0/+6
| | | | | | | 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.
* Add config for how many bcrypt rounds to use for password hashesMark Haines2015-10-161-0/+6
| | | | | 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.
* Implement configurable stats reportingDaniel Wagner-Hall2015-09-221-1/+1
| | | | | | | | | | 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.
* Issue macaroons as opaque auth tokensDaniel Wagner-Hall2015-08-181-0/+4
| | | | | | | | | | | | | 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
* Registration should be disabled by defaultErik Johnston2015-05-281-1/+1
|
* Allow generate-config to run against an existing config file to generate ↵Mark Haines2015-05-011-1/+1
| | | | default keys
* Allow --enable-registration to be passed on the commandlineMark Haines2015-04-301-3/+16
|
* Use disable_registration keys if they are presentMark Haines2015-04-301-0/+5
|
* Manually generate the default config yaml, remove most of the commandline ↵Mark Haines2015-04-301-33/+14
| | | | 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
* Fix spellingMark Haines2015-04-241-1/+1
|
* Call the super classes when generating configMark Haines2015-04-241-0/+1
|
* Fix --enable-registration flag to work if you don't give a valueErik Johnston2015-04-071-1/+1
|
* turn --disable-registration into --enable-registration, given the default is ↵Matthew Hodgson2015-03-301-11/+11
| | | | 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
* Comment.Erik Johnston2015-03-161-0/+3
|
* Allow enabling of registration with --disable-registration falseErik Johnston2015-03-131-2/+8
|
* PEP8Erik Johnston2015-03-131-1/+1
|
* Implement registering with shared secret.Erik Johnston2015-03-131-3/+17
|
* Disable registration by defaultErik Johnston2015-03-131-0/+4
|
* Add config option to disable registration.Erik Johnston2015-02-191-0/+33