52785ab768 refactored the login logic,
which, switching to nio's token login when being passed a token. The
token being passed is an *access* token though, not a *login* token, so
that fails and thereby breaks any tasks that use access tokens instead
of username/password for authenticating to matrix.
It also accidentally negated the logic on when to invalidate a token
upon logout, so that has been resolved as well.
52785ab768 refactored required and
mutually exclusive module parameters and meanwhile dropped some
arguments required for our matrix_token_login module. The change
made sense for most of our modules, but the matrix_token_login as the
only one doesn't need token or password, but definitely needs a key.
This fixes the data type of the admin flag, which was previously a
string. Now it's a bool. Additionally, if the admin flag is omitted,
it's now also ommitted in the JWT sent to the server, so that existing
admin status isn't revoked by a call which doesn't include it.
Matrix Login can be performed with username/password or token from each module.
`matrix_[uia]_login` and `matrix_logout` is only needed, longer operations are wanted.
modules called with username/password will logout automatically.
The login/logout process is handled by the helper class (except matrix_uia_login).
This module uses synapse's admin API to register users. It requires the
registration shared secret from synapse's config, and allows creating
admin users too.
This module can manage matrix membership in a given room by inviting, kicking or
banning a list specified users.
With the exclusive=True flag, it can be used to ensure that a given list of
members is in a room (and no one else). For this module, users invited into a
room count as members, as they have permissions to join the room.
Co-authored-by: Jan Christian Grünhage <jan.christian@gruenhage.xyz>
