From afa73853ca08f159f35bab577e5133d3e7beb4cc Mon Sep 17 00:00:00 2001
From: richvdh The following admin APIs were deprecated in Synapse 1.25
+(released on 2021-01-13) and have now been removed: Any scripts still using the above APIs should be converted to use the
+Delete Room API. Since Synapse 1.6.0 (2019-11-26) you can set a proxy for outbound HTTP requests via
http_proxy/https_proxy environment variables. This proxy was set for:Upgrading to v1.xx.0
+Removal of old Room Admin API
+
+
+POST /_synapse/admin/v1/purge_room
POST /_synapse/admin/v1/shutdown_room/<room_id>
Upgrading to v1.xx.0
Add support for routing outbound HTTP requests via a proxy for federation
To reclaim the disk space and return it to the operating system, you need to run
VACUUM FULL;
on the database.
https://www.postgresql.org/docs/current/sql-vacuum.html
-The old Purge room API is deprecated and will be removed in a future release. -See the new Delete Room API for more details.
-This API will remove all trace of a room from your database.
-All local users must have left the room before it can be removed.
-The API is:
-POST /_synapse/admin/v1/purge_room
-
-{
- "room_id": "!room:id"
-}
-
-You must authenticate using the access token of an admin user.
This API allows for the creation of users in an administrative and
non-interactive way. This is generally used for bootstrapping a Synapse
@@ -9764,94 +9761,6 @@ ignored in the same way as with PUT /_matrix/client/r0/rooms/{roomId}/send
Note that server notices must be enabled in homeserver.yaml
before this API
can be used. See the server notices documentation for more information.
The old Shutdown room API is deprecated and will be removed in a future release. -See the new Delete Room API for more details.
-Shuts down a room, preventing new joins and moves local users and room aliases automatically
-to a new room. The new room will be created with the user specified by the
-new_room_user_id
parameter as room administrator and will contain a message
-explaining what happened. Users invited to the new room will have power level
--10 by default, and thus be unable to speak. The old room's power levels will be changed to
-disallow any further invites or joins.
The local server will only have the power to move local user and room aliases to -the new room. Users on other servers will be unaffected.
-You will need to authenticate with an access token for an admin user.
-POST /_synapse/admin/v1/shutdown_room/{room_id}
room_id
- The ID of the room (e.g !someroom:example.com
)new_room_user_id
- Required. A string representing the user ID of the user that will admin
-the new room that all users in the old room will be moved to.room_name
- Optional. A string representing the name of the room that new users will be
-invited to.message
- Optional. A string containing the first message that will be sent as
-new_room_user_id
in the new room. Ideally this will clearly convey why the
-original room was shut down.If not specified, the default value of room_name
is "Content Violation
-Notification". The default value of message
is "Sharing illegal content on
-othis server is not permitted and rooms in violation will be blocked."
kicked_users
- An integer number representing the number of users that
-were kicked.failed_to_kick_users
- An integer number representing the number of users
-that were not kicked.local_aliases
- An array of strings representing the local aliases that were migrated from
-the old room to the new.new_room_id
- A string representing the room ID of the new room.Request:
-POST /_synapse/admin/v1/shutdown_room/!somebadroom%3Aexample.com
-
-{
- "new_room_user_id": "@someuser:example.com",
- "room_name": "Content Violation Notification",
- "message": "Bad Room has been shutdown due to content violations on this server. Please review our Terms of Service."
-}
-
-Response:
-{
- "kicked_users": 5,
- "failed_to_kick_users": 0,
- "local_aliases": ["#badroom:example.com", "#evilsaloon:example.com],
- "new_room_id": "!newroomid:example.com",
-},
-
-Note: This guide may be outdated by the time you read it. By nature of room shutdowns being performed at the database level, -the structure can and does change without notice.
-First, it's important to understand that a room shutdown is very destructive. Undoing a shutdown is not as simple as pretending it -never happened - work has to be done to move forward instead of resetting the past. In fact, in some cases it might not be possible -to recover at all:
-With all that being said, if you still want to try and recover the room:
-DELETE FROM blocked_rooms WHERE room_id = '!example:example.org';
-BEGIN; DELETE ...;
, verify you got 1 result, then COMMIT;
.You will have to manually handle, if you so choose, the following:
-Returns information about all local media usage of users. Gives the possibility to filter them by time and user.
@@ -12448,7 +12357,7 @@ connection errors. received for each stream so that on reconneciton it can start streaming from the correct place. Note: not all RDATA have valid tokens due to batching. SeeRdataCommand
for more details.
-An example iteraction is shown below. Each line is prefixed with '>' or '<' to indicate which side is sending, these are not included on the wire:
@@ -12744,7 +12653,7 @@ graph), and one where we remove redundant links (the transitive reduction of the links graph) e.g. if we have chainsC3 -> C2 -> C1
then the link C3 -> C1
would not be stored. Synapse uses the former implementations so that it doesn't
need to recurse to test reachability between chains.
-An example auth graph would look like the following, where chains have been
formed based on type/state_key and are denoted by colour and are labelled with
(chain ID, sequence number)
. Links are denoted by the arrows (links in grey
--
cgit 1.5.1