-
I think, the best way to handle this would be to actually add the new item to user's roster but never send the item to a client as a response to roster get request. So, all the existing storage and logic could be preserved with a small change of excluding such items when a roster result is created for a client.
-
Applied in changeset commit:tigase-server|2eb9b8d0.
-
Items with
SubscriptionType.none_pending_inare no longer included in the roster returned to the user. As for the security consideration -- I think it mostly relates to avoid broadcasting presence/probes to such contacts, but Tigase handles those differently and already took into consideration presence/transition state to avoid implied security problems, hence this was mostly cosmetic change.
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| RedmineID |
663
|
| Version |
tigase-server-7.1.0
|
| Estimation |
0
|
| Spent time |
0
|
How to replicate:
User A create account
User B create account
User A logins
User B logins
User A binds resource
User B binds resource
User A send presence available
User B send presence available
User A sends subscription request to User B
User B requests its roster : user A is in roster with subscription "none", ask "none".
I believe that User A should not enter the roster at all.
as per RFC6121
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.