32 lines
No EOL
2.3 KiB
Markdown
32 lines
No EOL
2.3 KiB
Markdown
# auth-mastodon.py
|
|
This is a Python script designed to run as an [ejabberd external auth](https://docs.ejabberd.im/developer/guide/#external) program, and validate user accounts directly from a [Mastodon](https://github.com/tootsuite/mastodon/) installation's database.
|
|
|
|
The code is derived from [ejabberd-auth-mysql](https://github.com/rankenstein/ejabberd-auth-mysql) and is licensed under the GNU GPLv3.
|
|
|
|
It is used on [Chinwag Social](https://social.chinwag.org) to provide XMPP messaging functionality to every account.
|
|
|
|
Discussion, questions and/or just saying hi in the [Chinwag Social Beergarden](xmpp:beergarden@rooms.chinwag.org?join) MUC is welcomed!
|
|
|
|
## Setup
|
|
Edit the `auth-mastodon.ini.default` file and add database connection credentials, and a location for the log files if desired. Rename it and place it somewhere the ejabberd user can read it.
|
|
|
|
I recommend not using your main Mastodon database user account for this, and instead granting SELECT privileges on the Mastodon *accounts* and *users* tables to your ejabberd user instead. The code here does not attempt any modification to the Mastodon tables at any point, so there's no reason to give it more than read-only rights.
|
|
|
|
The default locaction for the ini file is `/etc/ejabberd/auth-mastodon.ini` and can be changed with a command line option if desired:
|
|
```bash
|
|
$ auth-mastodon.py -c /usr/local/etc/auth-mastodon.ini
|
|
```
|
|
|
|
Then configure ejabberd to use `auth-mastodon.py` as an external authentication provider, as described in the [ejabberd docs](https://docs.ejabberd.im/admin/configuration/#external-script):
|
|
|
|
```yaml
|
|
auth_method: external
|
|
extauth_program: "/path/to/auth-mastodon.py"
|
|
```
|
|
Startup and shutdown is handled by the ejabberd process, there's no need to handle this separately via systemd or similar. If the process is killed, ejabberd will restart it.
|
|
|
|
## To Do
|
|
1. Verify domain part of request somehow. Maybe define a canonical domain to be used in config? Does this gain us anything at all?
|
|
2. Better error handling. Would be good to be more descriptive in the logs, perhaps.
|
|
3. Setup documentation is very brief, maybe include how to grant minimal permissions via pgsql.
|
|
4. Reconnection handling, exiting if a query fails would be a simple way to reload if a DB upgrade occurs but we should check if we're in a restart loop or something. |