mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-02-27 08:23:42 +01:00
Compare commits
6 commits
9fefe92fc5
...
cf41a60d52
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
cf41a60d52 | ||
|
|
d8be2ad942 | ||
|
|
21109b4d5b | ||
|
|
d4d31a8894 | ||
|
|
3c17aa3789 | ||
|
|
506bc1a164 |
|
|
@ -0,0 +1,2 @@
|
|||
Clarify that the stripped state in `invite_state` and `knock_state` in `GET /sync` response must
|
||||
include the full `m.room.member` event of the user.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Push rule IDs are globally unique within their kind.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Don't advertise `creator` field in description of room creation.
|
||||
|
|
@ -0,0 +1 @@
|
|||
The `server-name` segment of MXC URIs is sanitised differently from the `media-id` segment.
|
||||
|
|
@ -3386,10 +3386,10 @@ Unspecified room types are permitted through the use of
|
|||
### Creation
|
||||
|
||||
The homeserver will create an `m.room.create` event when a room is
|
||||
created, which serves as the root of the event graph for this room. This
|
||||
event also has a `creator` key which contains the user ID of the room
|
||||
creator. It will also generate several other events in order to manage
|
||||
permissions in this room. This includes:
|
||||
created, which serves as the root of the event graph for this room. The
|
||||
event `sender` is the user ID of the room creator. The server will also
|
||||
generate several other events in order to manage permissions in this room.
|
||||
This includes:
|
||||
|
||||
- `m.room.power_levels` : Sets the power levels of users and required power
|
||||
levels for various actions within the room such as sending events.
|
||||
|
|
|
|||
|
|
@ -134,9 +134,14 @@ entity isn't in the room.
|
|||
`mxc://` URIs are vulnerable to directory traversal attacks such as
|
||||
`mxc://127.0.0.1/../../../some_service/etc/passwd`. This would cause the
|
||||
target homeserver to try to access and return this file. As such,
|
||||
homeservers MUST sanitise `mxc://` URIs by allowing only alphanumeric
|
||||
(`A-Za-z0-9`), `_` and `-` characters in the `server-name` and
|
||||
`media-id` values. This set of whitelisted characters allows URL-safe
|
||||
homeservers MUST sanitise `mxc://` URIs by:
|
||||
|
||||
- restricting the `server-name` segment to valid
|
||||
[server names](/appendices/#server-name)
|
||||
- allowing only alphanumeric (`A-Za-z0-9`), `_` and `-` characters in
|
||||
the `media-id` segment
|
||||
|
||||
The resulting set of whitelisted characters allows URL-safe
|
||||
base64 encodings specified in RFC 4648. Applying this character
|
||||
whitelist is preferable to blacklisting `.` and `/` as there are
|
||||
techniques around blacklisted characters (percent-encoded characters,
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ Push Ruleset
|
|||
: A push ruleset *scopes a set of rules according to some criteria*. For
|
||||
example, some rules may only be applied for messages from a particular
|
||||
sender, a particular room, or by default. The push ruleset contains the
|
||||
entire set of scopes and rules.
|
||||
entire set of rules.
|
||||
|
||||
#### Push Rules
|
||||
|
||||
|
|
@ -91,10 +91,8 @@ A push rule is a single rule that states under what *conditions* an
|
|||
event should be passed onto a push gateway and *how* the notification
|
||||
should be presented. There are different "kinds" of push rules and each
|
||||
rule has an associated priority. Every push rule MUST have a `kind` and
|
||||
`rule_id`. The `rule_id` is a unique string within the kind of rule and
|
||||
its' scope: `rule_ids` do not need to be unique between rules of the
|
||||
same kind on different devices. Rules may have extra keys depending on
|
||||
the value of `kind`.
|
||||
`rule_id`. The `rule_id` is a unique string within the kind of rule.
|
||||
Rules may have extra keys depending on the value of `kind`.
|
||||
|
||||
The different `kind`s of rule, in the order that they are checked, are:
|
||||
|
||||
|
|
|
|||
|
|
@ -369,8 +369,14 @@ paths:
|
|||
description: |-
|
||||
The [stripped state events](/client-server-api/#stripped-state) that form the
|
||||
invite state.
|
||||
|
||||
MUST also include the `m.room.member` event of the user with a membership of
|
||||
`invite`, and using the same event format as joined rooms with the `event_id`
|
||||
and `origin_server_ts` fields.
|
||||
items:
|
||||
$ref: ../../event-schemas/schema/core-event-schema/stripped_state.yaml
|
||||
anyOf:
|
||||
- $ref: ../../event-schemas/schema/core-event-schema/stripped_state.yaml
|
||||
- $ref: definitions/client_event_without_room_id.yaml
|
||||
type: array
|
||||
knock:
|
||||
title: Knocked rooms
|
||||
|
|
@ -394,8 +400,14 @@ paths:
|
|||
description: |-
|
||||
The [stripped state events](/client-server-api/#stripped-state) that form the
|
||||
knock state.
|
||||
|
||||
MUST also include the `m.room.member` event of the user with a membership of
|
||||
`knock`, and using the same event format as joined rooms with the `event_id` and
|
||||
`origin_server_ts` fields.
|
||||
items:
|
||||
$ref: ../../event-schemas/schema/core-event-schema/stripped_state.yaml
|
||||
anyOf:
|
||||
- $ref: ../../event-schemas/schema/core-event-schema/stripped_state.yaml
|
||||
- $ref: definitions/client_event_without_room_id.yaml
|
||||
type: array
|
||||
leave:
|
||||
title: Left rooms
|
||||
|
|
@ -628,6 +640,8 @@ paths:
|
|||
"sender": "@alice:example.com",
|
||||
"type": "m.room.member",
|
||||
"state_key": "@bob:example.com",
|
||||
"event_id": "$19dl9d3848dJLle:example.com",
|
||||
"origin_server_ts": 1432735439654,
|
||||
"content": {
|
||||
"membership": "invite"
|
||||
}
|
||||
|
|
@ -652,6 +666,8 @@ paths:
|
|||
"sender": "@bob:example.com",
|
||||
"type": "m.room.member",
|
||||
"state_key": "@bob:example.com",
|
||||
"event_id": "$Fg83Kl3764di23a:example.com",
|
||||
"origin_server_ts": 143273039402,
|
||||
"content": {
|
||||
"membership": "knock"
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in a new issue