External authentication script for ejabberd to validate Mastodon accounts directly from the database. https://social.chinwag.org
Find a file
2025-01-22 10:42:40 +11:00
.editorconfig Specify EditorConfig settings for this code base. 2022-12-19 09:24:31 +11:00
.gitignore Add config file handling 2025-01-22 10:42:40 +11:00
auth-mastodon.ini.default Add config file handling 2025-01-22 10:42:40 +11:00
auth-mastodon.py Add config file handling 2025-01-22 10:42:40 +11:00
LICENSE Add GPL and README 2020-03-27 14:31:08 +11:00
README.md Add config file handling 2025-01-22 10:42:40 +11:00

auth-mastodon.py

This is a Python script designed to run as an ejabberd external auth program, and validate user accounts directly from a Mastodon installation's database.

The code is derived from ejabberd-auth-mysql and is licensed under the GNU GPLv3.

It is used on Chinwag Social to provide XMPP messaging functionality to every account.

Discussion, questions and/or just saying hi in the Chinwag Social Beergarden 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:

$ 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:

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.