nodejs/hookshot
nodejs/hookshot
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-hookshot.git synced 2025-03-10 13:17:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clarify permission system. (#925)

Browse Source 
* Clarify permission system.

* Rename 925.docs to 925.doc

Signed-off-by: Will Hunt <will@half-shot.uk>

---------

Signed-off-by: Will Hunt <will@half-shot.uk>
This commit is contained in:
Will Hunt 2024-04-16 22:06:41 +01:00 committed by GitHub
parent 45060f2b58
commit 79bfffc13a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 23 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
changelog.d/925.doc Normal file
View File

@ -0,0 +1 @@
Clarify permissions system documentation.

27
docs/setup.md
View File

@ -123,17 +123,34 @@ Each permission set can have a service. The `service` field can be:
- `challengehound`
- `*`, for any service.
The `level` determines what permissions a user has access to on the named service(s). They are
additive, one level grants all previous levels in addition to previous levels.
The `level` can be:
- `commands` Can run commands within connected rooms, but NOT log in to the bridge.
- `login` All the above, and can also log in to the bridge.
- `notifications` All the above, and can also bridge their notifications.
- `login` All the above, and can also log in to supported networks (such as GitHub, GitLab). This is the minimum level required to invite the bridge to rooms.
- `notifications` All the above, and can also bridge their own notifications. Only supported on GitHub.
- `manageConnections` All the above, and can create and delete connections (either via the provisioner, setup commands, or state events).
- `admin` All permissions. This allows you to perform administrative tasks like deleting connections from all rooms.
When permissions are checked, if a user matches any of the permissions set and one
of those grants the right level for a service, they are allowed access. If none of the
definitions match, they are denied.
If any of the permissions matches positively for a user, they are granted access. For example:
```yaml
permissions:
- actor: example.com
services:
- service: GitHub
level: manageConnections
- actor: "@badapple:example.com"
services:
- service: GitHub
level: login
```
would grant `@badapple:example.com` the right to `manageConnections` for GitHub, even though they
were explicitly named for a lower permission.
#### Example