eJabberd使用自定义用户表的配置方法与功能可行性问询

Great questions—integrating eJabberd with a custom user system is super common, and your concerns about avoiding duplicate data and ensuring server stability are totally valid. Let’s tackle each of your points in detail:

1. Will bypassing eJabberd’s default user table break server functionality (like roster management)? #

Short answer: No, as long as your configuration is set up correctly.

Here’s why and how to ensure roster and other features work smoothly:

• eJabberd’s roster (contact list) doesn’t depend on its default users table. Rosters are stored in separate tables (like rosteritems in SQL-backed setups) linked to the user’s JID. As long as the user can authenticate via your custom table (thanks to external auth), eJabberd will create and manage roster entries for them in your configured storage (SQL, in your case).
• The key is to configure eJabberd to persist all user-related data (rosters, message history, vCards) to your application’s database, not its internal Mnesia or default SQL tables. This way, even if eJabberd’s own users table is empty, all core functionality will still work because authentication is handled externally, and data lives in your system.
• Note: Tools like ejabberdctl will still try to read/write to the default users table by default. To avoid confusion, either:
  • Disable ejabberdctl user management commands (by restricting access or modifying the tool’s behavior), or
  • Ensure your team only uses your application’s API to manage users, not eJabberd’s native tools.

2. How to make eJabberd use your custom user table for all operations (avoid duplicate data)? #

To eliminate duplicate user data and fully rely on your custom table, follow these steps:

Step 1: Lock down eJabberd’s native user registration #

Prevent eJabberd from creating users in its own table by disabling native registration in ejabberd.yml:

# Disable public registration via XMPP
register_access: none
# Disable registration via ejabberdctl (optional but recommended)
commands_admin_access: configure
commands:
  - add_commands: [] # Remove user registration commands like "register"

Step 2: Ensure external auth is fully configured #

Double-check your external authentication script correctly validates users against your custom table. The script should accept input in eJabberd’s external auth format (username + domain) and return OK or FAIL based on your app’s user credentials. Example config in ejabberd.yml:

auth_method: external
extauth_program: "/usr/local/bin/your-app-auth-script.sh"
extauth_instances: 3 # Adjust based on your server load

Step 3: Configure eJabberd to store all user data in your application’s database #

Point eJabberd’s SQL storage to your app’s DB so rosters, messages, and other data are stored alongside your custom user table. Example config for MySQL:

sql_type: mysql
sql_server: "localhost"
sql_database: "your_app_database"
sql_username: "db_user"
sql_password: "db_secure_password"
sql_port: 3306
# Optional: If your table names differ from eJabberd defaults, map them here
sql_table_prefix: ""

With this setup, eJabberd won’t need its default users table at all—all authentication is handled externally, and all user-related data lives in your app’s DB.

Follow-up to your earlier question: Is it safe to ignore eJabberd’s user table? #

Absolutely safe, as long as:

• Your external auth script works reliably to validate users from your custom table.
• You’ve configured eJabberd to store all necessary data (rosters, messages, etc.) in your app’s database.

eJabberd’s core functionality (chat sessions, roster management, message routing) doesn’t require its native users table when using external authentication. The only caveat is avoiding native user management tools like ejabberdctl register, which would write to the default table unnecessarily.

内容的提问来源于stack exchange，提问作者Stefano Mtangoo