element-hq / element-hq/synapse

Consider not counting a user for the MAU limit when using an access token generated by the admin API

Open
#13,764 0 comments 0 reactions 0 assignees View on GitHub
A-MAU-Limiting O-Uncommon S-Minor T-Enhancement
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

This issue has been migrated from [#13764](https://github.com/matrix-org/synapse/issues/13764).

---

Currently if a server admin puppets a user by generating an access token for them using [the admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#login-as-a-user), the user is considered active (if they weren't already) and part of the MAU limit cohort (https://matrix-org.github.io/synapse/develop/usage/administration/monthly_active_users.html).

We recently had a case of an EMS customer experiencing issues, to which one of our proposed solution was that they puppet each of their users to apply a specific configuration for their push notifications. This ended up counting every user on their homeserver as active, even though ~2/3 of that number weren't actually active. This in turns is causing issues for EMS as the host is billed on monthly active users.

We probably shouldn't count a user as active if the access token they're using is one generated by the admin API, as it usually means a server admin is pupetting the account for maintenance reasons rather than actual activity. If we agree on doing this, though, we should also investigate how much this would allow server admins to circumvent MAU-based limiting/billing; ie how (un)limited would a user be if they used an access token provided by a server admin rather than logging in normally.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.