* Ability to send password reset emails
This changes the default behaviour of Synapse to send password reset
emails itself rather than through an identity server. The reasoning
behind the change is to prevent a malicious identity server from
being able to initiate a password reset attempt and then answering
it, successfully resetting their password, all without the user's
knowledge. This also aides in decentralisation by putting less
trust on the identity server itself, which traditionally is quite
centralised.
If users wish to continue with the old behaviour of proxying
password reset requests through the user's configured identity
server, they can do so by setting
email.enable_password_reset_from_is to True in Synapse's config.
Users should be able that with that option disabled (the default),
password resets will now no longer work unless email sending has
been enabled and set up correctly.
* Fix validation token lifetime email_ prefix
* Add changelog
* Update manifest to include txt/html template files
* Update db
* mark jinja2 and bleach as required dependencies
* Add email settings to default unit test config
* Update unit test template dir
* gen sample config
* Add html5lib as a required dep
* Modify check for smtp settings to be kinder to CI
* silly linting rules
* Correct html5lib dep version number
* one more time
* Change template_dir to originate from synapse root dir
* Revert "Modify check for smtp settings to be kinder to CI"
This reverts commit 6d2d3c9fd3.
* Move templates. New option to disable password resets
* Update templates and make password reset option work
* Change jinja2 and bleach back to opt deps
* Update email condition requirement
* Only import jinja2/bleach if we need it
* Update sample config
* Revert manifest changes for new res directory
* Remove public_baseurl from unittest config
* infer ability to reset password from email config
* Address review comments
* regen sample config
* test for ci
* Remove CI test
* fix bug?
* Run bg update on the master process
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.
* Add AllowEncodedSlashes to apache
Add `AllowEncodedSlashes On` to apache config to support encoding for v3 rooms. "The AllowEncodedSlashes setting is not inherited by virtual hosts, and virtual hosts are used in many default Apache configurations, such as the one in Ubuntu. The workaround is to add the AllowEncodedSlashes setting inside a <VirtualHost> container (/etc/apache2/sites-available/default in Ubuntu)." Source: https://stackoverflow.com/questions/4390436/need-to-allow-encoded-slashes-on-apache
* change allowencodedslashes to nodecode
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.
This endpoint isn't much use for its intended purpose if you first need to get
yourself an admin's auth token.
I've restricted it to the `/_synapse/admin` path to make it a bit easier to
lock down for those concerned about exposing this information. I don't imagine
anyone is using it in anger currently.
