mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-24 11:44:08 +02:00
Compare commits
1 commit
1381bd037b
...
debb8cc5e0
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
debb8cc5e0 |
|
|
@ -1 +0,0 @@
|
||||||
Push rule IDs are globally unique within their kind.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Don't advertise `creator` field in description of room creation.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
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
|
### Creation
|
||||||
|
|
||||||
The homeserver will create an `m.room.create` event when a room is
|
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. The
|
created, which serves as the root of the event graph for this room. This
|
||||||
event `sender` is the user ID of the room creator. The server will also
|
event also has a `creator` key which contains the user ID of the room
|
||||||
generate several other events in order to manage permissions in this room.
|
creator. It will also generate several other events in order to manage
|
||||||
This includes:
|
permissions in this room. This includes:
|
||||||
|
|
||||||
- `m.room.power_levels` : Sets the power levels of users and required power
|
- `m.room.power_levels` : Sets the power levels of users and required power
|
||||||
levels for various actions within the room such as sending events.
|
levels for various actions within the room such as sending events.
|
||||||
|
|
|
||||||
|
|
@ -134,14 +134,9 @@ entity isn't in the room.
|
||||||
`mxc://` URIs are vulnerable to directory traversal attacks such as
|
`mxc://` URIs are vulnerable to directory traversal attacks such as
|
||||||
`mxc://127.0.0.1/../../../some_service/etc/passwd`. This would cause the
|
`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,
|
target homeserver to try to access and return this file. As such,
|
||||||
homeservers MUST sanitise `mxc://` URIs by:
|
homeservers MUST sanitise `mxc://` URIs by allowing only alphanumeric
|
||||||
|
(`A-Za-z0-9`), `_` and `-` characters in the `server-name` and
|
||||||
- restricting the `server-name` segment to valid
|
`media-id` values. This set of whitelisted characters allows URL-safe
|
||||||
[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
|
base64 encodings specified in RFC 4648. Applying this character
|
||||||
whitelist is preferable to blacklisting `.` and `/` as there are
|
whitelist is preferable to blacklisting `.` and `/` as there are
|
||||||
techniques around blacklisted characters (percent-encoded characters,
|
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
|
: 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
|
example, some rules may only be applied for messages from a particular
|
||||||
sender, a particular room, or by default. The push ruleset contains the
|
sender, a particular room, or by default. The push ruleset contains the
|
||||||
entire set of rules.
|
entire set of scopes and rules.
|
||||||
|
|
||||||
#### Push Rules
|
#### Push Rules
|
||||||
|
|
||||||
|
|
@ -91,8 +91,10 @@ 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
|
event should be passed onto a push gateway and *how* the notification
|
||||||
should be presented. There are different "kinds" of push rules and each
|
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 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.
|
`rule_id`. The `rule_id` is a unique string within the kind of rule and
|
||||||
Rules may have extra keys depending on the value of `kind`.
|
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`.
|
||||||
|
|
||||||
The different `kind`s of rule, in the order that they are checked, are:
|
The different `kind`s of rule, in the order that they are checked, are:
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue