[ejabberd] resending authorization problem?

Badlop badlop at gmail.com
Tue Nov 17 16:19:09 MSK 2009


2009/10/22 Jesse Thompson <jesse.thompson at doit.wisc.edu>:
> using ejabberd 2.0.5

The problem is still present in ejabbed 2.1.0. Let's investigate.


> Is ejabberd preventing the presence packets in this situation?

Seems so. Let's look at the rules defined for incoming and outgoing in
http://www.process-one.net/docs/ejabberd/devdoc/trunk/mod_roster.erl.html#in_state_change-3


> Scenario:
>  UserA "removes authorization from" UserB
>  Assumptions:
>    both users are using Psi v0.13
>    both users have enabled the "auto-authorize contacts" option
>    both users are online

Those are the calls that ejabberd makes:
  mod_roster:out_state_change(none,none,unsubscribe) -> none
  mod_roster:in_state_change(both,none,unsubscribe) -> {to,none}
  mod_roster:in_state_change(both,none,unsubscribed) -> {from,none}
  mod_roster:out_state_change(to,none,unsubscribed) -> none
  mod_roster:in_state_change(from,none,unsubscribed) -> none


> Symptom:
>  UserA sees "subscription: to" for UserB, and is still able to see UserB's
> status in roster
>  UserB sees "Subscription: from" for UserA, and is not able to see UserA's
> status in roster

>  UserA can fix the problem by removing UserB from roster and adding UserB
> back again

>  UserB can't fix the problem by "resending authorization to" UserA
> (expected)

>  UserB can fix the problem by "rerequesting authorization from" UserA
> (expected)

In this case, this is called:
  mod_roster:out_state_change(from,none,subscribe) -> {from,out}
  mod_roster:in_state_change(to,none,subscribe) -> {to,in}


>  UserA can't fix the problem by "rerequesting authorization from" UserB
> (expected)

>  UserA can't fix the problem by "resending authorization to" UserB (not
> expected)

This is called:
  mod_roster:out_state_change(to,none,subscribed) -> none
  mod_roster:in_state_change(from,none,subscribed) -> none


> So, if I understand how this is supposed to work, I think there is a problem
> with "resending authorization to" in this case.
>
> I have XML consoles open for both users.  I can see the presence XML stanza
> being sent by UserA, but UserB's client never received it. Actually, just to
> be thorough in case I'm mixing up resending and rerequesting, both types of
> presence packets are not received by UserB.
>

Right. Making two quick changes in the rules, it seems to work.

Replace:
  in_state_change(from, none, subscribed)   -> none;
with:
  in_state_change(from, none, subscribed)   -> {both, none};

And replace:
  out_state_change(to,   none, subscribed)   -> none;
with:
  out_state_change(to,   none, subscribed)   -> {both, none};


With that change, this is called:
  mod_roster:out_state_change(to,none,subscribed) -> {both,none}
  mod_roster:in_state_change(from,none,subscribed) -> {both,none}

Finally both userA and userB can see presence of each other.

If you try, comment if this solves all the problems or not.



---
Badlop
ProcessOne


More information about the ejabberd mailing list