Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.

Commit 73636ca

Browse files
Convert admin api docs to markdown (#10089)
So that they render nicely in mdbook (see #10086), and so that we no longer have a mix of structured text languages in our documentation (excluding files outside of `docs/`).
1 parent 5325f03 commit 73636ca

File tree

9 files changed

+1160
-1132
lines changed

9 files changed

+1160
-1132
lines changed

changelog.d/10089.doc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Convert the remaining Admin API documentation files to markdown.

docs/admin_api/account_validity.md

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
# Account validity API
2+
3+
This API allows a server administrator to manage the validity of an account. To
4+
use it, you must enable the account validity feature (under
5+
`account_validity`) in Synapse's configuration.
6+
7+
## Renew account
8+
9+
This API extends the validity of an account by as much time as configured in the
10+
`period` parameter from the `account_validity` configuration.
11+
12+
The API is:
13+
14+
```
15+
POST /_synapse/admin/v1/account_validity/validity
16+
```
17+
18+
with the following body:
19+
20+
```json
21+
{
22+
"user_id": "<user ID for the account to renew>",
23+
"expiration_ts": 0,
24+
"enable_renewal_emails": true
25+
}
26+
```
27+
28+
29+
`expiration_ts` is an optional parameter and overrides the expiration date,
30+
which otherwise defaults to now + validity period.
31+
32+
`enable_renewal_emails` is also an optional parameter and enables/disables
33+
sending renewal emails to the user. Defaults to true.
34+
35+
The API returns with the new expiration date for this account, as a timestamp in
36+
milliseconds since epoch:
37+
38+
```json
39+
{
40+
"expiration_ts": 0
41+
}
42+
```

docs/admin_api/account_validity.rst

Lines changed: 0 additions & 42 deletions
This file was deleted.
Lines changed: 32 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,4 @@
1-
Purge History API
2-
=================
1+
# Purge History API
32

43
The purge history API allows server admins to purge historic events from their
54
database, reclaiming disk space.
@@ -13,65 +12,67 @@ delete the last message in a room.
1312

1413
The API is:
1514

16-
``POST /_synapse/admin/v1/purge_history/<room_id>[/<event_id>]``
15+
```
16+
POST /_synapse/admin/v1/purge_history/<room_id>[/<event_id>]
17+
```
1718

18-
To use it, you will need to authenticate by providing an ``access_token`` for a
19-
server admin: see `README.rst <README.rst>`_.
19+
To use it, you will need to authenticate by providing an `access_token` for a
20+
server admin: [Admin API](README.rst)
2021

2122
By default, events sent by local users are not deleted, as they may represent
2223
the only copies of this content in existence. (Events sent by remote users are
2324
deleted.)
2425

2526
Room state data (such as joins, leaves, topic) is always preserved.
2627

27-
To delete local message events as well, set ``delete_local_events`` in the body:
28+
To delete local message events as well, set `delete_local_events` in the body:
2829

29-
.. code:: json
30-
31-
{
32-
"delete_local_events": true
33-
}
30+
```
31+
{
32+
"delete_local_events": true
33+
}
34+
```
3435

3536
The caller must specify the point in the room to purge up to. This can be
3637
specified by including an event_id in the URI, or by setting a
37-
``purge_up_to_event_id`` or ``purge_up_to_ts`` in the request body. If an event
38+
`purge_up_to_event_id` or `purge_up_to_ts` in the request body. If an event
3839
id is given, that event (and others at the same graph depth) will be retained.
39-
If ``purge_up_to_ts`` is given, it should be a timestamp since the unix epoch,
40+
If `purge_up_to_ts` is given, it should be a timestamp since the unix epoch,
4041
in milliseconds.
4142

4243
The API starts the purge running, and returns immediately with a JSON body with
4344
a purge id:
4445

45-
.. code:: json
46-
47-
{
48-
"purge_id": "<opaque id>"
49-
}
46+
```json
47+
{
48+
"purge_id": "<opaque id>"
49+
}
50+
```
5051

51-
Purge status query
52-
------------------
52+
## Purge status query
5353

5454
It is possible to poll for updates on recent purges with a second API;
5555

56-
``GET /_synapse/admin/v1/purge_history_status/<purge_id>``
56+
```
57+
GET /_synapse/admin/v1/purge_history_status/<purge_id>
58+
```
5759

58-
Again, you will need to authenticate by providing an ``access_token`` for a
60+
Again, you will need to authenticate by providing an `access_token` for a
5961
server admin.
6062

6163
This API returns a JSON body like the following:
6264

63-
.. code:: json
64-
65-
{
66-
"status": "active"
67-
}
65+
```json
66+
{
67+
"status": "active"
68+
}
69+
```
6870

69-
The status will be one of ``active``, ``complete``, or ``failed``.
71+
The status will be one of `active`, `complete`, or `failed`.
7072

71-
Reclaim disk space (Postgres)
72-
-----------------------------
73+
## Reclaim disk space (Postgres)
7374

7475
To reclaim the disk space and return it to the operating system, you need to run
7576
`VACUUM FULL;` on the database.
7677

77-
https://www.postgresql.org/docs/current/sql-vacuum.html
78+
<https://www.postgresql.org/docs/current/sql-vacuum.html>

docs/admin_api/register_api.md

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# Shared-Secret Registration
2+
3+
This API allows for the creation of users in an administrative and
4+
non-interactive way. This is generally used for bootstrapping a Synapse
5+
instance with administrator accounts.
6+
7+
To authenticate yourself to the server, you will need both the shared secret
8+
(`registration_shared_secret` in the homeserver configuration), and a
9+
one-time nonce. If the registration shared secret is not configured, this API
10+
is not enabled.
11+
12+
To fetch the nonce, you need to request one from the API:
13+
14+
```
15+
> GET /_synapse/admin/v1/register
16+
17+
< {"nonce": "thisisanonce"}
18+
```
19+
20+
Once you have the nonce, you can make a `POST` to the same URL with a JSON
21+
body containing the nonce, username, password, whether they are an admin
22+
(optional, False by default), and a HMAC digest of the content. Also you can
23+
set the displayname (optional, `username` by default).
24+
25+
As an example:
26+
27+
```
28+
> POST /_synapse/admin/v1/register
29+
> {
30+
"nonce": "thisisanonce",
31+
"username": "pepper_roni",
32+
"displayname": "Pepper Roni",
33+
"password": "pizza",
34+
"admin": true,
35+
"mac": "mac_digest_here"
36+
}
37+
38+
< {
39+
"access_token": "token_here",
40+
"user_id": "@pepper_roni:localhost",
41+
"home_server": "test",
42+
"device_id": "device_id_here"
43+
}
44+
```
45+
46+
The MAC is the hex digest output of the HMAC-SHA1 algorithm, with the key being
47+
the shared secret and the content being the nonce, user, password, either the
48+
string "admin" or "notadmin", and optionally the user_type
49+
each separated by NULs. For an example of generation in Python:
50+
51+
```python
52+
import hmac, hashlib
53+
54+
def generate_mac(nonce, user, password, admin=False, user_type=None):
55+
56+
mac = hmac.new(
57+
key=shared_secret,
58+
digestmod=hashlib.sha1,
59+
)
60+
61+
mac.update(nonce.encode('utf8'))
62+
mac.update(b"\x00")
63+
mac.update(user.encode('utf8'))
64+
mac.update(b"\x00")
65+
mac.update(password.encode('utf8'))
66+
mac.update(b"\x00")
67+
mac.update(b"admin" if admin else b"notadmin")
68+
if user_type:
69+
mac.update(b"\x00")
70+
mac.update(user_type.encode('utf8'))
71+
72+
return mac.hexdigest()
73+
```

docs/admin_api/register_api.rst

Lines changed: 0 additions & 68 deletions
This file was deleted.

0 commit comments

Comments
 (0)