[Security] Unsubscribe on Userdelete (Was: [Standards] Password protected rooms)
pavlix at pavlix.net
Fri Feb 13 11:12:12 CST 2009
On Fri, 13 Feb 2009 11:52:19 +0100
Alexander Gnauck <gnauck at ag-software.de> wrote:
> > Thats an very interesting point - in many respects. Two more
> > examples:
> > - I have a service with many users from other servers subscribed.
> > As there is no unsubscribe if the user has been deleted, I have
> > many "zombie"-subscription. I can only check the subscriptions from
> > my own server if the accounts still exist. And even that is not so
> > easy.
> > - A friend subscribed my presence. He was some time in hospital, so
> > I never noticed, that his account was deleted on the server (due to
> > inactivity?). As the jid came back online I wrote him gladly, how
> > he is after the surgery... I realised very late, that the account
> > was now new assigned.
> I had a similar problem when I unregistered my jabber.org account by
> error with a beta version of a client. The subscription was out of
> sync, and still is for
> many of my contacts, because server don't route my subscription
> requests. The only solution is to delete the contact on both sides
> and subscribe again.
I had similar problems in other scenarios too...
> > I see only the solution, that there has to be an
> > unsubscribe-request to every contact in the roster of an user if
> > that user is going to be deleted.
> right, this is how it should (MUST) be done.
This does not help enough (though it catches the easiest cases).
I believe the subscription stuff in XMPP should be further re-thinked.
There are many real-world cases that break integrity of subscriptions
* User delete
* Server switch (if you're not careful enough about the database)
* User grants subscription without being asked (I believe this is an
* Some important <presence/> stanza gets lost due to lost connection
* Various server errors (happenes once, but the integrity is lost)
* Other cases
I believe the only way is to implement some sort of auto-correction
that occures upon any sort of interaction.
E.g. the server could check the subscription when the following
suspicious (though many times valid) events occur.
* You got a <presence/> from someone you're not subscribed to
* You got a <message/> (or <iq/>) from someone you're subscribed to but
you haven't got his presence
* User tries to subscribe to someone he's already subscribed (and
* Of course, user deletion should trigger unsubscribe, but it would be
better to distinguish it from regular unsubscribe.
It would also be good to have some sort of redirection support that
would allow an account to be in a state between registered and
Could be as simple as a <redirect/> element in any error
answers. Supporting clients could then offer the user to *delete*
the contact or *replace* the contact with his new ID, request
subscription and retain group, local name and comments.
> Alexander Gnauck
> xmpp:gnauck at jabber.org
Freelance consultant and trainer
in networking, communications and security.
Jabber, Mail: pavlix(at)pavlix.net
More information about the Security