|
Sivakumar Ekambaram opened 1 decade ago
|
|
Version 5.2.0 is being closed now, and this is a bigger task, at least a week of work. Therefore we cannot include the fix in this version. However, we will work on this as soon as the 5.2.0 is released and include fix in version 5.2.1 this fall. |
|
|
This is a generic issue, I am moving it to the Tigase XMPP Server project and assigning it to the target version 5.2.1 |
|
|
I think this is duplicate to #663 and it looks like I have relatively simple fix for this. We will fix the problem within next 3 months. |
|
Applied in changeset commit:tigase-server|2eb9b8d0. |
|
|
duplicate of #663 |
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| RedmineID |
1396
|
| Version |
tigase-server-7.1.0
|
Duplicate
Issue Votes (0)
Watchers (0)
We had earlier brought this issue (listed below) to your notice and you had mentioned the following.
"This is a consequence of a historical decision to keep all subscription states in user's roster. The first version of the XMPP RFC was not that strong about adding new items to the roster. We plan to change this, however, practical impact of the issue is very low and the work effort to fix this is significant so it is pushed back and it is still on TODO list."
Due to a new feature being added in our product, we are running into this issue more frequently now than earlier. Hence, we would like to know your plans (some tentative timeline) on fixing it.
Add/Subscribe/Remove Issue:
===========================
Setup:
User1 = pc1
User2 = pc2
Both users are online and has empty contact list.
Steps to reproduce:
pc1 adds pc2 as contact
pc1 subscribes to pc2 (& no action – approve/deny – taken by pc2)
pc1 removes pc2; Now we see in the pc2 client, pc1 as its contact, which it should NOT.
Our analysis:
After step2 (pc1 subscribes to pc2), we see pc2 has pc1 in its roster list with subscription as "none_pending_in". Tigase is adding pc1 into pc2 roster list with subs as ‘none’ first and immediately following it with an update of subs as “none_pending_in”. This is INCORRECT as per rfc 6121 in two places:
A) http://xmpp.org/rfcs/rfc6121.html#sub-request-inbound
3.1.3. Server Processing of Inbound Subscription Request
...
Security Warning: Until and unless the contact approves the subscription request as described under Section 3.1.4, the contact's server MUST NOT add an item for the user to the contact's roster.
...
B) http://xmpp.org/rfcs/rfc6121.html#substates
"None + Pending In" = Contact and user are not subscribed to each other, and contact has sent user a subscription request but user has not replied yet. This state might or might not be reflected in the user's roster, as follows: if the user has created a roster item for the contact then the server MUST maintain that roster item and also note the existence of the inbound presence subscription request, whereas if the user has not created a roster item for the contact then the user's server MUST note the existence of the inbound presence subscription request but MUST NOT create a roster item for the contact (instead, the server MUST wait until the user has approved the subscription request before adding the contact to the user's roster).
Continuing on with the analysis, since it created wrongly the roster item for pc1 in pc2 roster list in Step2, in Step3, it updates the subs state to “none” for pc1 in pc2 roster list and sends a roster push to the pc2 client and hence pc2 client shows it incorrectly.