#782 mod_vjud fails to get all users with vjud_mode = "all" when using external authentication (cyrus_sasl)
Reporter
Davy
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Component-Community
Priority-Medium
Status-New
Type-Defect
Davy
on
Prosody version: 0.9.10, on CentOS 6
steps to reproduce:
1. configure Prosody with SQL storage as default and Cyrus SASL authentication with LDAP backend
2. configure vjud with vjud_mode = "all" to (try to) have a nice user directory (for a corporate use)
3. try to find users in Pidgin with anything else than a JID (first name, name...)
I’m expecting the list of matching users to be returned.
I can see a backtrace of mod_vjud in the log when it’s trying to iterate on the list of users "for username in users() do" that has a nil value.
The users() function is defined as a simple "return usermanager.users(base_host);".
BTW, a test could be made to check that the list is not nil, to avoid a backtrace...
My understanding is that the list of users is made with an SQL query on the "accounts" store (my default storage engine is SQL, so the query seems to be with store = "accounts"). Unfortunately, that list is empty when authentication is delegated to Cyrus SASL. When I try to search with a JID, the user is found, because the vjud module code is using usermanager.user_exists(username, hostname) and finds the user’s Vcard details. So, I guess that in that case the SQL query is probably searching a result in another store, perhaps vcard (store = 'vcard').
A possible fix could be a change in the store type that users are searched for in the SQL query (accounts or vcard).
The function seems to be keyval_store:users() in mod_storage_sql.lua and the associated SQL query is here:
local stmt, err = dosql("SELECT DISTINCT `user` FROM `prosody` WHERE `host`=? AND `store`=?", host, self.store);
That could be replaced by something like:
local stmt, err = dosql("SELECT DISTINCT `user` FROM `prosody` WHERE `host`=? AND (`store`=? OR `store`=?)", host, self.store, <something pointing to the vcard store name, which should be set to 'vcard'>);
Zash
on
Changes
tags Component-Community
Zash
on
Tagging issue as affecting a community module, not officially supported by the Prosody team.
Prosody version: 0.9.10, on CentOS 6 steps to reproduce: 1. configure Prosody with SQL storage as default and Cyrus SASL authentication with LDAP backend 2. configure vjud with vjud_mode = "all" to (try to) have a nice user directory (for a corporate use) 3. try to find users in Pidgin with anything else than a JID (first name, name...) I’m expecting the list of matching users to be returned. I can see a backtrace of mod_vjud in the log when it’s trying to iterate on the list of users "for username in users() do" that has a nil value. The users() function is defined as a simple "return usermanager.users(base_host);". BTW, a test could be made to check that the list is not nil, to avoid a backtrace... My understanding is that the list of users is made with an SQL query on the "accounts" store (my default storage engine is SQL, so the query seems to be with store = "accounts"). Unfortunately, that list is empty when authentication is delegated to Cyrus SASL. When I try to search with a JID, the user is found, because the vjud module code is using usermanager.user_exists(username, hostname) and finds the user’s Vcard details. So, I guess that in that case the SQL query is probably searching a result in another store, perhaps vcard (store = 'vcard'). A possible fix could be a change in the store type that users are searched for in the SQL query (accounts or vcard). The function seems to be keyval_store:users() in mod_storage_sql.lua and the associated SQL query is here: local stmt, err = dosql("SELECT DISTINCT `user` FROM `prosody` WHERE `host`=? AND `store`=?", host, self.store); That could be replaced by something like: local stmt, err = dosql("SELECT DISTINCT `user` FROM `prosody` WHERE `host`=? AND (`store`=? OR `store`=?)", host, self.store, <something pointing to the vcard store name, which should be set to 'vcard'>);
Tagging issue as affecting a community module, not officially supported by the Prosody team.
Changes