mod_auth_sqlite

Accounts and bans in a SQLite database. Part of the bundled plug-ins.

mod_auth_sqlite is uhub's storage plug-in. It keeps registered accounts in a SQLite database — scaling well past a hand-edited text file — and, since 0.8.0, also persists the hub's bans so they survive a restart. The uhub-passwd tool creates and manages the database.

Loading

plugin /var/lib/uhub/mod_auth_sqlite.so "file=/etc/uhub/users.db"

Configuration

Option	Default	Description
file	—	Path to the SQLite database (required).
exclusive	no	When enabled, only accounts in this database may log in — any other nick is denied rather than passed on to another auth plug-in.

Nicknames are matched case-insensitively when authenticating.

Ban persistence

Without a storage plug-in, bans live only in the hub's in-memory ACL and are lost on restart. mod_auth_sqlite implements the ban-storage callbacks, so the hub writes every ban through to the database as it is created and asks the database at login whether a connecting user is banned.

Each stored ban keeps its expiry and its reason, which means:

• A timed ban made with !ban nick 30m still expires on time after a restart.
• A user refused on reconnect is told why they were banned, and how long is left — the reason given to !ban is stored and shown back.
• On a linked hub, bans and unbans propagate across the cluster and each hub persists its own copy.

Bans lifted at runtime with !unban are removed from the database too. Note that bans are not written back to the file_acl ACL file — that file remains hand-maintained for static ban_nick / ban_cid / deny_nick / deny_ip rules.

Self-service registration

To let users register their own nick and change their own password, load mod_selfregister after this plug-in:

plugin /var/lib/uhub/mod_auth_sqlite.so "file=/etc/uhub/users.db"
plugin /var/lib/uhub/mod_selfregister.so

For a simple file-based store without a database, see mod_auth_simple.