ejabberd - Comments for "mod_shared_roster_ldap"

Try the following patch: ---

porridge — Sat, 04 Sep 2010 16:24:59 +0000

Try the following patch:

--- a/src/mod_shared_roster_ldap_helpers.erl
+++ b/src/mod_shared_roster_ldap_helpers.erl
@@ -118,9 +118,13 @@ group_entries_to_dict(GroupIDAttr, GroupDescAttr, GroupMemberAttr, Host, Extract
                     JIDs = lists:foldl(
                         fun({ok, UID}, L) ->
                             PUID = jlib:nodeprep(UID),
-                            case AuthProcessor(PUID, Host) of
-                                true -> [{PUID, Host} | L];
-                                _ -> L
+                            case PUID of
+                                error -> L;
+                                _ ->
+                                    case AuthProcessor(PUID, Host) of
+                                        true -> [{PUID, Host} | L];
+                                        _ -> L
+                                    end
                             end;
                            (_, L) ->
                                L

First of all, if you want me

porridge — Sat, 04 Sep 2010 15:58:53 +0000

First of all, if you want me to notice, please report mod_shared_roster_ldap issues in http://www.ejabberd.im/mod_shared_roster_ldap or (better yet) the bug tracker in https://alioth.debian.org/projects/ejabberd-msrl/

It seems this error condition has taken place because ejabberd_auth:is_user_exists/2 was called with atom `error` (NOT string "error") in group_entries_to_dict (line "case AuthProcessor(PUID, Host) of").

This in turn seems can only happen when jlib:nodeprep/1 returns the atom `error` for some reason.

The trace is so long because in branch 2.1.x the atom triggers an error condition deep within eldap_filter's guts. This should be easier to spot in the trunk code, as is_user_exists has an is_list() guard.

As for why nodeprep() can return `error` - one case might be when the UID is over 1KiB long. I suspect that is what happens in your case. I'll try to come up with a patch to cover that case by simply ignoring such long usernames.

However you'll be better off by tweaking your LDAP filters not to return useless entries in the first place.

i have applied this patch:

newc0mer — Tue, 31 Aug 2010 07:32:05 +0000

i have applied this patch: http://github.com/processone/ejabberd/commit/3024bb0cbf359f3e14b5386ed14...
now the error message looks like this:

=ERROR REPORT==== 2010-08-31 09:28:18 ===
E(<0.453.0>:ejabberd_auth:256) : The authentication module ejabberd_auth_ldap returned an error
when checking user error in server "example.com"
Error message: {{case_clause,
{'EXIT',
{function_clause,
[{lists,flatmap,
[#Fun,error]},
{eldap_filter,do_sub,2},
{eldap_filter,check,2},
{eldap_filter,scan,5},
{eldap_filter,parse,2},
{ejabberd_auth_ldap,find_user_dn,2},
{ejabberd_auth_ldap,is_user_exists_ldap,2},
{ejabberd_auth_ldap,is_user_exists,2}]}}},
[{eldap_filter,parse,2},
{ejabberd_auth_ldap,find_user_dn,2},
{ejabberd_auth_ldap,is_user_exists_ldap,2},
{ejabberd_auth_ldap,is_user_exists,2},
{ejabberd_auth,'-is_user_exists/2-fun-0-',3},
{lists,any,2},
{mod_shared_roster_ldap_helpers,
'-group_entries_to_dict/7-fun-0-',4},
{lists,foldl,3}]}

I think beams can be compressed

mfoss — Mon, 30 Aug 2010 22:09:58 +0000

newc0mer wrote:

something other I think that it is strange:
file mod_shared_roster.beam: gzip compressed data, from Unix
file mod_shared_roster_ldap.beam: data
file mod_shared_roster_ldap_helpers.beam: data
file mod_sic.beam: gzip compressed data, from Unix

all files are gzip compressed, except the ones I have compiled manually.

I think the beam files included in ejabberd binary packages are usually compiled with an additional compression option.

i^ve downloaded the lastest

newc0mer — Mon, 30 Aug 2010 13:00:05 +0000

i^ve downloaded the lastest ejabberd (2.1.5) and compiled eveything manually. It looks better now - at least I get an error msg:
=ERROR REPORT==== 2010-08-30 14:55:08 ===
E(<0.355.0>:ejabberd_auth:256) : The authentication module ejabberd_auth_ldap returned an error
when checking user error in server "example.com"
Error message: {{case_clause,
{'EXIT',
{function_clause,
[{lists,map,[#Fun,error]},
{eldap_filter,do_sub,2},
{eldap_filter,check,2},
{eldap_filter,scan,5},
{eldap_filter,parse,2},
{ejabberd_auth_ldap,find_user_dn,2},
{ejabberd_auth_ldap,is_user_exists_ldap,2},
{ejabberd_auth_ldap,is_user_exists,2}]}}},
[{eldap_filter,parse,2},
{ejabberd_auth_ldap,find_user_dn,2},
{ejabberd_auth_ldap,is_user_exists_ldap,2},
{ejabberd_auth_ldap,is_user_exists,2},
{ejabberd_auth,'-is_user_exists/2-fun-0-',3},
{lists,any,2},
{mod_shared_roster_ldap_helpers,
'-group_entries_to_dict/7-fun-0-',4},
{lists,foldl,3}]}

probably someone knows more about this error?

something other I think that

newc0mer — Thu, 26 Aug 2010 13:42:54 +0000

all files are gzip compressed, except the ones I have compiled manually.. i followed these steps to create them:
http://ejabberd-msrl.alioth.debian.org/doc/0.5.1/msrl.html#htoc7

btw: there was no error/success message at the point i've compiled the files with erlc... it just made the .beam files...