* Add registration token UIA type
MSC: https://github.com/matrix-org/matrix-doc/pull/3231
**Note**: This introduces the endpoint as v1 rather than r0 given the global versioning changes landed between the acceptance of the MSC and now.
* Fix swagger
* Changelogs
* Update data/api/client-server/registration_tokens.yaml
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Fixes#3465. The change adds a line explicitly warning developers that the base_url of client well_known may or may not include a trailing slash and to be prepared to handle both cases.
* Clarify that E0 and E1 are not returned
* Clarify that ASCII art diagram 2 refers to diagram 1
* Correct third ASCII art diagram
To match the spacing in. Borked in the move to new docs format.
55aed1d296/specification/client_server_api.rst (L1610-L1615)
* Make ASCII art 3 follow from ASCII art 2
* Explain how to fill the gap
* Create 3543.clarification
* Update content/client-server-api/_index.md
Co-authored-by: Travis Ralston <travisr@matrix.org>
This fixes the behaviour to match what synapse implements in practice.
If you use threepidCreds, you will just get an error about a missing
threepid_creds field. Synapse also treats this as an object. All clients
also seem to send threepid_creds, if they work on Synapse. Since
matrix.org requires an email currently for registration, most clients
that implement registration, will hit this issue.
a0f48ee89d/synapse/handlers/ui_auth/checkers.py (L145)fixes#3156fixes#2189
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
* Fully specify room versions
* Misc typo clarifications
* Try to clarify redactions a bit
* Update content/client-server-api/_index.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update content/rooms/v6.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update content/rooms/v6.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Better describe client considerations
* Doc template params
* Move redaction "new stuff" to v3
* Remove unhelpful sentences about "here follows unchanged stuff"
* Simplify event signing text
* Clean up handling redactions sections
* Move v4's event schema to unchanged section
* Update content/rooms/v4.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
* Cut/paste room version spec to its own page
* Move grammar to bottom + add feature matrix
The version grammar is not as interesting as the actual room versions, so this moves that whole section to the bottom.
* Fix all links to room versions
* Clarify how redacted_because actually works for events
* changelog
* mention federation
* Fix wording
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
The Pagination section in the C-S API was, basically, full of rubbish. I think that anything of any value it contained was repeated either directly on the API definitions or in the text specific to syncing at https://spec.matrix.org/unstable/client-server-api/#syncing.
The conventions I've added to the Appendices are based on the discussions in #1898. They are there because I don't want to have to go through it all again next time we add a paginated API.
Fixes: #1898Fixes: #2268
This change drops the Origin and Accept header names from the
recommended value for the CORS Access-Control-Allow-Headers header. Per
the CORS protocol, it’s not necessary or useful to include them.
Per-spec at https://fetch.spec.whatwg.org/#forbidden-header-name, Origin
is a “forbidden header name” set by the browser and that frontend
JavaScript code is never allowed to set.
So the value of Access-Control-Allow-Headers isn’t relevant to Origin or
in general to other headers set by the browser itself — the browser
never ever consults the Access-Control-Allow-Headers value to confirm
that it’s OK for the request to include an Origin header.
And per-spec at https://fetch.spec.whatwg.org/#cors-safelisted-request-header,
Accept is a “CORS-safelisted request-header”, which means that browsers
allow requests to contain the Accept header regardless of whether the
Access-Control-Allow-Headers value contains "Accept".
So it’s unnecessary for the Access-Control-Allow-Headers to explicitly
include Accept. Browsers will not perform a CORS preflight for requests
containing an Accept request header.
Related: Related: https://github.com/matrix-org/synapse/pull/10114
Signed-off-by: Michael[tm] Smith <mike@w3.org>
Travis Ralston