|
|
|
@ -255,7 +255,7 @@ condition applies throughout the request signing process.
|
|
|
|
Step 2 add Authorization header:
|
|
|
|
Step 2 add Authorization header:
|
|
|
|
|
|
|
|
|
|
|
|
GET /target HTTP/1.1
|
|
|
|
GET /target HTTP/1.1
|
|
|
|
Authorization: X-Matrix origin=origin.hs.example.com,key="ed25519:key1",sig="ABCDEF..."
|
|
|
|
Authorization: X-Matrix origin="origin.hs.example.com",destination="destination.hs.example.com",key="ed25519:key1",sig="ABCDEF..."
|
|
|
|
Content-Type: application/json
|
|
|
|
Content-Type: application/json
|
|
|
|
|
|
|
|
|
|
|
|
<JSON-encoded request body>
|
|
|
|
<JSON-encoded request body>
|
|
|
|
@ -283,14 +283,52 @@ def authorization_headers(origin_name, origin_signing_key,
|
|
|
|
|
|
|
|
|
|
|
|
for key, sig in signed_json["signatures"][origin_name].items():
|
|
|
|
for key, sig in signed_json["signatures"][origin_name].items():
|
|
|
|
authorization_headers.append(bytes(
|
|
|
|
authorization_headers.append(bytes(
|
|
|
|
"X-Matrix origin=%s,key=\"%s\",sig=\"%s\"" % (
|
|
|
|
"X-Matrix origin=\"%s\",destination=\"%s\",key=\"%s\",sig=\"%s\"" % (
|
|
|
|
origin_name, key, sig,
|
|
|
|
origin_name, destination_name, key, sig,
|
|
|
|
)
|
|
|
|
)
|
|
|
|
))
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
|
|
return ("Authorization", authorization_headers)
|
|
|
|
return ("Authorization", authorization_headers[0])
|
|
|
|
```
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The format of the Authorization header is given in
|
|
|
|
|
|
|
|
[RFC 7235](https://datatracker.ietf.org/doc/html/rfc7235#section-2.1). In
|
|
|
|
|
|
|
|
summary, the header begins with authorization scheme `X-Matrix`, followed by
|
|
|
|
|
|
|
|
one or more spaces, followed by a comma-separated list of parameters written as
|
|
|
|
|
|
|
|
name=value pairs. The names are case insensitive and order does not matter. The
|
|
|
|
|
|
|
|
values must be enclosed in quotes if they contain characters that are not
|
|
|
|
|
|
|
|
allowed in `token`s, as defined in
|
|
|
|
|
|
|
|
[RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6); if a
|
|
|
|
|
|
|
|
value is a valid `token`, it may or may not be enclosed in quotes. Quoted
|
|
|
|
|
|
|
|
values may include backslash-escaped characters. When parsing the header, the
|
|
|
|
|
|
|
|
recipient must unescape the characters. That is, a backslash-character pair is
|
|
|
|
|
|
|
|
replaced by the character that follows the backslash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For compatibility with older servers, the sender should
|
|
|
|
|
|
|
|
- only include one space after `X-Matrix`,
|
|
|
|
|
|
|
|
- only use lower-case names, and
|
|
|
|
|
|
|
|
- avoid using backslashes in parameter values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For compatibility with older servers, the recipient should allow colons to be
|
|
|
|
|
|
|
|
included in values without requiring the value to be enclosed in quotes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The authorization parameters to include are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- `origin`: the server name of the sending server. This is the same as the
|
|
|
|
|
|
|
|
`origin` field from JSON described in step 1.
|
|
|
|
|
|
|
|
- `destination`: {{< added-in v="1.3" >}} the server name of the receiving
|
|
|
|
|
|
|
|
sender. This is the same as the `destination` field from the JSON described
|
|
|
|
|
|
|
|
in step 1. For compatibility with older servers, recipients should accept
|
|
|
|
|
|
|
|
requests without this parameter, but MUST always send it. If this property
|
|
|
|
|
|
|
|
is included, but the value does not match the receiving server's name, the
|
|
|
|
|
|
|
|
receiving server must deny the request with an HTTP status code 401
|
|
|
|
|
|
|
|
Unauthorized.
|
|
|
|
|
|
|
|
- `key`: the ID, including the algorithm name, of the sending server's key used
|
|
|
|
|
|
|
|
to sign the request.
|
|
|
|
|
|
|
|
- `signature`: the signature of the JSON as calculated in step 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unknown parameters are ignored.
|
|
|
|
|
|
|
|
|
|
|
|
### Response Authentication
|
|
|
|
### Response Authentication
|
|
|
|
|
|
|
|
|
|
|
|
Responses are authenticated by the TLS server certificate. A homeserver
|
|
|
|
Responses are authenticated by the TLS server certificate. A homeserver
|
|
|
|
@ -356,13 +394,15 @@ specification](/rooms).
|
|
|
|
Whenever a server receives an event from a remote server, the receiving
|
|
|
|
Whenever a server receives an event from a remote server, the receiving
|
|
|
|
server must ensure that the event:
|
|
|
|
server must ensure that the event:
|
|
|
|
|
|
|
|
|
|
|
|
1. Is a valid event, otherwise it is dropped.
|
|
|
|
1. Is a valid event, otherwise it is dropped. For an event to be valid, it
|
|
|
|
|
|
|
|
must contain a `room_id`, and it must comply with the event format of
|
|
|
|
|
|
|
|
that [room version](/rooms).
|
|
|
|
2. Passes signature checks, otherwise it is dropped.
|
|
|
|
2. Passes signature checks, otherwise it is dropped.
|
|
|
|
3. Passes hash checks, otherwise it is redacted before being processed
|
|
|
|
3. Passes hash checks, otherwise it is redacted before being processed
|
|
|
|
further.
|
|
|
|
further.
|
|
|
|
4. Passes authorization rules based on the event's auth events,
|
|
|
|
4. Passes authorization rules based on the event's auth events,
|
|
|
|
otherwise it is rejected.
|
|
|
|
otherwise it is rejected.
|
|
|
|
5. Passes authorization rules based on the state at the event,
|
|
|
|
5. Passes authorization rules based on the state before the event,
|
|
|
|
otherwise it is rejected.
|
|
|
|
otherwise it is rejected.
|
|
|
|
6. Passes authorization rules based on the current state of the room,
|
|
|
|
6. Passes authorization rules based on the current state of the room,
|
|
|
|
otherwise it is "soft failed".
|
|
|
|
otherwise it is "soft failed".
|
|
|
|
|
Hubert Chathi
3 years ago