I would think the bug lies at least in client "a" since the client adds "b" to its roster even though it was not requested. In defense of the client developer, it is a bit complicated to handle this correctly since the client would need to "remember" outstanding subscription requests between runs of the client software. I doubt many (or any?) clients do this, and just assume any "subscribed" stanzas received are valid reponses from a previous subscription request.
However are you also saying that "b" can also correctly see the presence of "a", or does it just pass on the subscribed stanza the client "a" and not do anything further? Is client "b" added to the client "a"'s roster on the server or does client "a" just add it in the GUI - but when the client restarts the client "b" does not reappear in the roster? If it is added to the roster on the server, this is a problem with the server implementations. I would think the server should remember what outstanding subscription requests there are for every user on the system and reject any unsolicited subscribed requests that are sent. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Konieczny Sent: Sunday, February 06, 2005 10:12 AM To: [email protected] Subject: [jdev] Presence subscription handling bugs in various Jabbersoftware Hello, Most of us know, that some transports abuse <presence type='subscribed'/> stanzas, in a way which is now forbidden by the XMPP-IM specification. That is done because of a very old bug in jabberd-1.x based servers, which accept and process this stanza. It is not good, when anyone is able to add himself to other's roster. Now, when more and more servers aim at the XMPP compliance I thought such features and abuses are going to die. Unfortunately it seems that I am wrong. Some users of my server complain, that some users of other servers are able to add themselves to their rosters. It looks like this: a - user of my server A - my server B - the other server b - the other user They are connected like this: a ----(c2s)---- A ------- (s2s) ------ B ------- b (any (ejabberd) (some (some client) server) client) "a" does not have "b" in his roster, then "b" does "something" that add it to "a"'s roster by sending <presence type='subscribed'/> although "a" have never requested it. Two such cases where reported to me. In the first case, the server "B" was jabber.org (jabberd-1.4.x AFAIK), and the client "b" was (most probably) Psi. In the second case "B" was WP Jabber (JSM/JSM version 1.1.5 for pthreaded server (Linux 2.6.x)), and "b" Psi (Psi/0.9.3 (SuSE Linux 9.2 (i586))). Server "A" is always the same: ejabberd/0.7.5 (unix/linux 2.6.7) Client "a" doesn't matter. Please note, that for that scenario to work there must be bugs on both servers ("A" which should not accept that stanza and "B", which should not forward it from its client) and a misfeature on the client "b" (I have found nothing in the XMPP specs that forbids client to send unsolicited <presence type="subscribed" />). So we have bugs in at least free server implementations (ejabberd, jabberd 1.4.x and WP Jabber) and annoying (for users of buggy servers) misfeature of at least one client (I may be wrong here if it is not the client which generates the "subscribed" stanza). That doesn't look good, as it seems a very big part of global Jabber infrastructure is broken :-( Or maybe I am wrong and there is only one bug somehere? I will submit a bug report to the maintainers of the software I use (ejabberd). And I ask you to check your software, and submit the bugs reports or fix the bugs too. Greets, Jacek _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
