mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-05-01 22:54:10 +02:00
Compare commits
4 commits
0f84add695
...
9ac91f6e21
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
9ac91f6e21 | ||
|
|
205fa06076 | ||
|
|
2a8a6d7833 | ||
|
|
b6a127b5cb |
|
|
@ -1 +1 @@
|
|||
Add note to each endpoint that uses capability negotiation and document expected response when the capability is not available.
|
||||
Add example to each endpoint when the capability is not available.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
In room versions 8 through 12, clarify that "sufficient permission to invite users" on restricted joins also includes being a joined member of the room.
|
||||
|
|
@ -74,7 +74,7 @@ The rules are as follows:
|
|||
1. If membership state is `join` or `invite`, allow.
|
||||
2. If the `join_authorised_via_users_server` key in `content`
|
||||
is not a user with sufficient permission to invite other
|
||||
users, reject.
|
||||
users or is not a joined member of the room, reject.
|
||||
3. Otherwise, allow.
|
||||
6. If the `join_rule` is `public`, allow.
|
||||
7. Otherwise, reject.
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ The rules are as follows:
|
|||
1. If membership state is `join` or `invite`, allow.
|
||||
2. If the `join_authorised_via_users_server` key in `content`
|
||||
is not a user with sufficient permission to invite other
|
||||
users, reject.
|
||||
users or is not a joined member of the room, reject.
|
||||
3. Otherwise, allow.
|
||||
6. If the `join_rule` is `public`, allow.
|
||||
7. Otherwise, reject.
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ The rules are as follows:
|
|||
1. If membership state is `join` or `invite`, allow.
|
||||
2. If the `join_authorised_via_users_server` key in `content`
|
||||
is not a user with sufficient permission to invite other
|
||||
users, reject.
|
||||
users or is not a joined member of the room, reject.
|
||||
3. Otherwise, allow.
|
||||
6. If the `join_rule` is `public`, allow.
|
||||
7. Otherwise, reject.
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ The rules are as follows:
|
|||
1. If membership state is `join` or `invite`, allow.
|
||||
2. If the `join_authorised_via_users_server` key in `content`
|
||||
is not a user with sufficient permission to invite other
|
||||
users, reject.
|
||||
users or is not a joined member of the room, reject.
|
||||
3. Otherwise, allow.
|
||||
6. If the `join_rule` is `public`, allow.
|
||||
7. Otherwise, reject.
|
||||
|
|
|
|||
|
|
@ -99,10 +99,6 @@ paths:
|
|||
has been removed, making this endpoint behave as though it was `false`.
|
||||
This results in this endpoint being an equivalent to `/3pid/bind` rather
|
||||
than dual-purpose.
|
||||
|
||||
This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
|
||||
Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
|
||||
to determine if this endpoint is available.
|
||||
operationId: post3PIDs
|
||||
deprecated: true
|
||||
security:
|
||||
|
|
@ -218,10 +214,6 @@ paths:
|
|||
Homeservers should prevent the caller from adding a 3PID to their account if it has
|
||||
already been added to another user's account on the homeserver.
|
||||
|
||||
This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
|
||||
Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
|
||||
to determine if this endpoint is available.
|
||||
|
||||
{{% boxes/warning %}}
|
||||
Since this endpoint uses User-Interactive Authentication, it cannot be used when the access token was obtained
|
||||
via the [OAuth 2.0 API](/client-server-api/#oauth-20-api).
|
||||
|
|
@ -363,10 +355,6 @@ paths:
|
|||
Unlike other endpoints, this endpoint does not take an `id_access_token`
|
||||
parameter because the homeserver is expected to sign the request to the
|
||||
identity server instead.
|
||||
|
||||
This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
|
||||
Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
|
||||
to determine if this endpoint is available.
|
||||
operationId: delete3pidFromAccount
|
||||
security:
|
||||
- accessTokenQuery: []
|
||||
|
|
|
|||
|
|
@ -34,10 +34,6 @@ paths:
|
|||
valid access token is provided. The homeserver SHOULD NOT revoke the
|
||||
access token provided in the request. Whether other access tokens for
|
||||
the user are revoked depends on the request parameters.
|
||||
|
||||
This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
|
||||
Clients SHOULD check the value of the [`m.change_password` capability](/client-server-api/#mchange_password-capability)
|
||||
to determine if this endpoint is available.
|
||||
security:
|
||||
- {}
|
||||
- accessTokenQuery: []
|
||||
|
|
|
|||
|
|
@ -29,11 +29,6 @@ paths:
|
|||
Servers MAY reject `null` values. Servers that accept `null` values SHOULD store
|
||||
them rather than treating `null` as a deletion request. Clients that want to delete a
|
||||
field, including its key and value, SHOULD use the `DELETE` endpoint instead.
|
||||
|
||||
This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation)
|
||||
depending on the `keyName`. Clients SHOULD check the value of the
|
||||
[`m.profile_fields` capability](/client-server-api/#mprofile_fields-capability) to detect
|
||||
which `keyName`s they are allowed to modify.
|
||||
operationId: setProfileField
|
||||
security:
|
||||
- accessTokenQuery: []
|
||||
|
|
|
|||
Loading…
Reference in a new issue