To allow supplying the `client_secret` in a file, instead of directly in the configuration. I've found that ESS prefer this method in the past, so the entire config does not need to be a secret.
To deactivate users, we need their `actor_user_id` (MAS-specific). I don't believe there's a way to get this from Synapse. So, we store user's detailed in a namespaced table upon registering them, along with the creation timestamp, and deactivate them once they're considered expired.
In order to get an access token for a user, one needs to create a personal session on MAS.
We now do so, and extract the access token and device ID from the response.
TODO: We're handing back the MAS user ID as the device ID. Is that correct?
In order to create and manage users with MAS enabled, we'll need to
reach out to the MAS admin API. We can do so automatically by requesting
an admin-enabled token, assuming a matching client has been configured
on the MAS side.
Add some config options for the guest module (OAuth2 client) side.
Move them into the module folder so that they'll be properly included
in distribution builds, such as when installing this module via pip.
Also reword copyright headers to refer to the project root instead of
the repository root, which isn't included in distribution builds.
Set license to multi-license of AGPL + Element Commercial, and add
associated license files to the repository root.
This does not add a notice of "This file includes modifications" to any
files because they were only moved and relicensed, but otherwise
unmodified.
The exception is run_in_venv.sh, which is a rewrite of upstream's
run_in_venv.js and thus lacks the original copyright entirely.
Andrew Morgan