Looking for ejabberd docs?

To access the most up-to-date ejabberd documentation, please visit docs.ejabberd.im »

Roster Subscription Problem

Submitted by guntanis on Wed, 2007-03-07 23:11

There is a problem on the way ejabberd manages subscriptions, and it doesn't seems like it's really RFC3921 compliant, so I'd catalog it as a bug. I tested this behavior with other jabber flavors and I couldn't recreate ejabberd's.

When I add a buddy, it gets added in both, my roster and his roster, with subscription none. Even if I haven't accepted him or even if I declined his request. While the correct behavior should be that the user gets added after I accepted him.

Is there a reason for this behavior, is there a way to fix this behavior?

I've been looking on the config files and I've googled this problem out for a while now, without any luck, I'd appreciate all the help/guidance you can provide me on this.

Thanks

Fixed.

Submitted by guntanis on Fri, 2007-03-09 00:04.

mod_roster.erl
Current Code:

-ifdef(PSI_ROSTER_WORKAROUND).

process_iq(From, To, IQ) ->
    #iq{sub_el = SubEl} = IQ,
    #jid{lserver = LServer} = From,
    case lists:member(LServer, ?MYHOSTS) of
        true ->
            ResIQ = process_local_iq(From, To, IQ),
            ejabberd_router:route(From, From,
                                  jlib:iq_to_xml(ResIQ)),
            ignore;
        _ ->
            IQ#iq{type = error, sub_el = [SubEl, ?ERR_ITEM_NOT_FOUND]}
    end.

-else.

CODE THAT FIX THE BEHAVIOR DESCRIBED IN THE LAST POST

-ifdef(PSI_ROSTER_WORKAROUND).

process_iq(From, To, IQ) ->
    #iq{sub_el = SubEl} = IQ,
    #jid{lserver = LServer} = From,
    case lists:member(LServer, ?MYHOSTS) of
        true ->
            ResIQ = process_local_iq(From, To, IQ),
            ejabberd_router:route(From, To,
                                  jlib:iq_to_xml(ResIQ)),
            ignore;
        _ ->
            IQ#iq{type = error, sub_el = [SubEl, ?ERR_ITEM_NOT_FOUND]}
    end.

-else.

This might help someone in the future, I don't know if psi will behave correctly, but this will make it RFC compliant.

Cheers!
Jorge Guntanis

thank you !

Submitted by mremond on Fri, 2007-03-09 08:48.

Hello,

Thank you. We will have a look at this code and we will make some more testing with various client on it.

--
Mickaël Rémond
Process-one

The only impact of this

Submitted by teo on Fri, 2007-03-09 10:51.

The only impact of this "fix" is that clients will never get or set roster items.

True

Submitted by guntanis on Mon, 2007-03-12 23:50.

True,
For some reason when I tested it the first time it worked. Later on I tried and didn't work.
I'm trying to make it work, if anyone of you has any pointers please let me know.
If I get it to work, I'll post the _real_ fix :P

Thanks

Jorge

The problem is that ejabberd

Submitted by teo on Tue, 2007-03-13 17:07.

The problem is that ejabberd stores incoming subscription requests in users' rosters. So, if you want to fix it you have to store them somwhere else (in a separate table).

right, that's where it

Submitted by guntanis on Tue, 2007-03-13 20:52.

right, that's where it becomes not RFC Compliant:

RFC 3921
Page: 32
Section: 8.1
The server MUST NOT send presence subscription requests or roster
pushes to unavailable resources, nor to available resources that have
not requested the roster.

Basically what ejabberd is doing is:
1. client1 sends a subscription request to client2
2. server pushes client1 to client2's roster with subscription none. [while client2 didn't request it.]