projectmoon
/
fediblockhole-misskey
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'main' into release-v0.4.1

This commit is contained in:
Justin Warren 2023-01-16 07:31:18 +11:00
parent d7d0859030 8d2f7a7f35
commit 44d4e78045
No known key found for this signature in database
1 changed files with 35 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
README.md
View File

@ -81,20 +81,28 @@ token.
The application needs the `admin:read:domain_blocks` OAuth scope, but
unfortunately this scope isn't available in the current application screen
(v4.0.2 of Mastodon at time of writing). There is a way to do it with scopes,
but it's really dangerous, so I'm not going to tell you what it is here.
(v4.0.2 of Mastodon at time of writing, but this has been fixed in the main
branch).
A better way is to ask the instance admin to connect to the PostgreSQL database
and add the scope there, like this:
You can allow full `admin:read` access, but be aware that this authorizes
someone to read all the data in the instance. That's asking a lot of a remote
instance admin who just wants to share domain_blocks with you.
For now, you can ask the instance admin to update the scope in the database
directly like this:
```
UPDATE oauth_access_tokens
UPDATE oauth_applications as app
SET scopes = 'admin:read:domain_blocks'
WHERE token='<your_app_token>';
FROM oauth_access_tokens as tok
WHERE app.id = tok.application_id
AND app.name = '<the_app_name>'
;
```
When that's done, FediBlockHole should be able to use its token to read domain
blocks via the API.
When that's done, regenerate the token (so it has the new scopes) in the
application screen in the instance GUI. FediBlockHole should then able to use
the app token to read domain blocks via the API, but nothing else.
Alternately, you could ask the remote instance admin to set up FediBlockHole and
use it to dump out a CSV blocklist from their instance and then put it somewhere
@ -104,12 +112,17 @@ as explained below.
### Writing instance blocklists
To write domain blocks into an instance requires both the `admin:read` and
`admin:write:domain_blocks` OAuth scopes. The `read` scope is used to read the
current list of domain blocks so we update ones that already exist, rather than
trying to add all new ones and clutter up the instance. It's also used to check
if the instance has any accounts that follow accounts on a domain that is about
to get `suspend`ed and automatically drop the block severity to `silence` level
so people have time to migrate accounts before a full defederation takes effect.
`admin:write:domain_blocks` OAuth scopes.
The tool needs `admin:read:domain_blocks` scope to read the current list of
domain blocks so we update ones that already exist, rather than trying to add
all new ones and clutter up the instance.
`admin:read` access is needed to check if the instance has any accounts that
follow accounts on a domain that is about to get `suspend`ed and automatically
drop the block severity to `silence` level so people have time to migrate
accounts before a full defederation takes effect. Unfortunately, the statistics
measure used to learn this information requires `admin:read` scope.
You can add `admin:read` scope in the application admin screen. Please be aware
that this grants full read access to all information in the instance to the
@ -122,12 +135,15 @@ chmod o-r <configfile>
You can also grant full `admin:write` scope to the application, but if you'd
prefer to keep things more tightly secured you'll need to use SQL to set the
scopes in the database:
scopes in the database and then regenerate the token:
```
UPDATE oauth_access_tokens
UPDATE oauth_applications as app
SET scopes = 'admin:read admin:write:domain_blocks'
WHERE token='<your_app_token>';
FROM oauth_access_tokens as tok
WHERE app.id = tok.application_id
AND app.name = '<the_app_name>'
;
```
When that's done, FediBlockHole should be able to use its token to authorise