| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Synapse 1.27.0rc2 (2021-02-11)
==============================
Features
--------
- Further improvements to the user experience of registration via single sign-on. ([\#9297](https://github.com/matrix-org/synapse/issues/9297))
Bugfixes
--------
- Fix ratelimiting introduced in v1.27.0rc1 for invites to respect the `ratelimit` flag on application services. ([\#9302](https://github.com/matrix-org/synapse/issues/9302))
- Do not automatically calculate `public_baseurl` since it can be wrong in some situations. Reverts behaviour introduced in v1.26.0. ([\#9313](https://github.com/matrix-org/synapse/issues/9313))
Improved Documentation
----------------------
- Clarify the sample configuration for changes made to the template loading code. ([\#9310](https://github.com/matrix-org/synapse/issues/9310))
|
| |
| |
| |
| | |
This breaks some people's configurations (if their Client-Server API
is not accessed via port 443).
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea is that the parse_config method of extension modules can raise either a ConfigError or a JsonValidationError,
and it will be magically turned into a legible error message. There's a few components to it:
* Separating the "path" and the "message" parts of a ConfigError, so that we can fiddle with the path bit to turn it
into an absolute path.
* Generally improving the way ConfigErrors get printed.
* Passing in the config path to load_module so that it can wrap any exceptions that get caught appropriately.
|
|
|
|
| |
If the SAML metadata includes multiple IdPs it is necessary to
specify which IdP to redirect users to for authentication.
|
|
|
|
| |
Updates the sample configuration with the pysaml2 configuration for
accepting clock skew/drift between the homeserver and IdP.
|
|
|
| |
add some mdui:UIInfo element examples for saml2_config in homeserver.yaml
|
| |
|
| |
|
|
|
| |
Regressed in #8037.
|
|
|
| |
Fixes https://github.com/matrix-org/synapse/issues/6583
|
|
|
|
|
|
|
| |
Hopefully this mostly speaks for itself. I also did a bit of cleaning up of the
error handling.
Fixes #8047
|
| |
|
|
|
|
| |
docs, default configs, comments. Nothing very significant.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Expose `return_html_error`, and allow it to take a Jinja2 template instead of a raw string
* Clean up exception handling in SAML2ResponseResource
* use the existing code in `return_html_error` instead of re-implementing it
(giving it a jinja2 template rather than inventing a new form of template)
* do the exception-catching in the REST layer rather than in the handler
layer, to make sure we catch all exceptions.
|
|
|
|
|
|
| |
Also adjust sample_config.yaml
Signed-off-by: Lars Franke <frcl@mailbox.org>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also add some JS to it to process any error we might have in the URI
(see #6893).
|
| |
|
| |
|
|
|
|
|
|
| |
If an error happened while processing a SAML AuthN response, or a client
ends up doing a `GET` request to `/authn_response`, then render a
customisable error page rather than a confusing error.
|
|
|
| |
Turns out that figuring out a remote user id for the SAML user isn't quite as obvious as it seems. Factor it out to the SamlMappingProvider so that it's easy to control.
|
| |
|
|
|
|
|
| |
Add a linting script that enforces all boolean values in the default config be lowercase.
This has annoyed me for a while so I decided to fix it.
|
| |
|
|\ |
|
| |\
| | |
| | | |
Fix a bug with saml attribute maps.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes a bug where the default attribute maps were prioritised over
user-specified ones, resulting in incorrect mappings.
The problem is that if you call SPConfig.load() multiple times, it adds new
attribute mappers to a list. So by calling it with the default config first,
and then the user-specified config, we would always get the default mappers
before the user-specified mappers.
To solve this, let's merge the config dicts first, and then pass them to
SPConfig.
|
|/ /
| |
| |
| |
| |
| | |
We want to assign unique mxids to saml users based on an incrementing
suffix. For that to work, we need to record the allocated mxid in a separate
table.
|
|/
|
|
| |
It' still not great, thanks to the nested dictionaries, but it's better.
|
| |
|
|
|
|
| |
This allows us to correctly handle `allow_unsolicited: False`.
|
|\ |
|
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| | |
Also: share the saml client between redirect and response handlers.
|
|/
|
|
| |
Signed-off-by: Alexander Trost <galexrt@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
This implements both a SAML2 metadata endpoint (at
`/_matrix/saml2/metadata.xml`), and a SAML2 response receiver (at
`/_matrix/saml2/authn_response`). If the SAML2 response matches what's been
configured, we complete the SSO login flow by redirecting to the client url
(aka `RelayState` in SAML2 jargon) with a login token.
What we don't yet have is anything to build a SAML2 request and redirect the
user to the identity provider. That is left as an exercise for the reader.
|