#887 closed defect (fixed)

Rejecting a buddy request on jabber actually accepts it

Reported by: anonymous Owned by: wilmer
Priority: major Milestone:
Component: Jabber Version: devel
Keywords: patch Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:



I tried to reject a buddy request, but got added to a list anyway:

13:38 <@root> jabber(me@…) - New request: The user someone@… wants to add you to his/her buddy list.
13:38 <@root> You can use the yes/no commands to accept/reject this request.
13:48 <@me> no
13:48 <@root> jabber(me@…) - Rejected: The user someone@… wants to add you to his/her buddy list.
13:48 <@root> jabber(me@…) - someone@… just accepted your authorization request
13:48 -!- someone [someone@…] has joined &bitlbee

This isn't supposed to work like this, is it?

Attachments (0)

Change History (13)

comment:1 Changed at 2012-01-10T17:18:47Z by anonymous

I just encountered this as well with 3.0.4-bzr855-1 on Debian. Not pasting the output since it's exactly the same as the original submitter's.

comment:2 Changed at 2012-01-12T10:42:25Z by wilmer

Hrmm. The "just accepted your auth request" message is misleading, on GTalk I get that one pretty often without adding anyone. GTalk has somewhat odd contact list behaviour, I think it often automatically adds contacts as you send them e-mails, etc.

Not sure if that's related though. I'd have to check in xmlconsole what BitlBee sends when you use the "no" command. I'm pretty sure it's doing the right thing..

comment:3 Changed at 2012-01-30T21:42:45Z by wilmer

I've heard more reports of this now. I'mm still convinced this is GTalk behaving oddly, but it's definitely fishy...

comment:4 Changed at 2012-02-20T17:14:14Z by tom

I can confirm this happens consistently. And it definitely gives the person the ability to message you because as soon as I get that "accepted your request" message, the bot starts sending messages. I've found that simply doing nothing when presented with the yes/no works, though.

comment:5 Changed at 2012-02-21T11:26:15Z by Wilmer van der Gaast <wilmer@…>

Indeed, so I'm wondering if I should just do nothing when the user says no. The only problem then is that you'll keep getting the question.

comment:6 Changed at 2012-02-23T09:13:03Z by Tom Knight <tomk@…>

Same thing is happening here. Last time it happened I blocked the user from GTalk but now if I log in to Gmail the person who has requested to be added in BitlBee isn't there to block. And if I try to block from BitlBee it says "Command `block' not supported by this protocol".

So I'll have to go with ignoring the requests for now.

comment:7 Changed at 2012-05-23T20:44:43Z by siberion@…


This still happens in 3.0.5.

Recently, a bunch of bots (presumably), which I most certainly have not had email contact with (not even as a passive receiver, I checked my spam folder), attempted to add me and I observed the same behaviour as described above.

comment:8 Changed at 2014-02-13T12:28:14Z by synergism@…

Just for the record, the correct command is 'remove', not 'block'. And you can find people who aren't online on your buddy list with 'blist all'. The bug still exists in and was identified on irc:

08:17 < pesco> protocols/jabber/jabber_util.c:jabber_buddy_ask_no
08:18 < pesco> wow
08:18 < pesco> it's a simple typo
08:18 < pesco> presence_send_request( bla->ic, bla->handle, "subscribed" );
08:18 < pesco> should say "unsubscribed"

comment:9 Changed at 2014-02-13T12:30:11Z by anonymous

Sorry, I wasn't exactly clear about when to 'remove'. You can say 'no'. The bug causes the person to be added to your list. Then you use 'remove' immediately. That's my workaround.

comment:10 Changed at 2014-02-13T12:43:29Z by pesco

Component: BitlBeeJabber
Keywords: patch added
OS version/distro: gentoo
Owner: set to wilmer
Priority: normalmajor
Summary: Rejecting a buddy request on google talk failsRejecting a buddy request on jabber actually accepts it
Version: 3.0.4devel

This is simply what looks like a copy-and-paste mistake in protocols/jabber/jabber_util.c. When the user answers no, bitlbee actually sends "yes". This is the handler for the "no" answer as of r1010:

static void jabber_buddy_ask_no( void *data )
        struct jabber_buddy_ask_data *bla = data;
        presence_send_request( bla->ic, bla->handle, "subscribed" );
        g_free( bla->handle );
        g_free( bla );

That should say "unsubscribed", cf. the RFC. Er...

--- protocols/jabber/jabber_util.c      2011-12-26 18:56:10 +0000
+++ protocols/jabber/jabber_util.c      2014-02-13 12:39:43 +0000
@@ -288,7 +288,7 @@
        struct jabber_buddy_ask_data *bla = data;
-       presence_send_request( bla->ic, bla->handle, "subscribed" );
+       presence_send_request( bla->ic, bla->handle, "unsubscribed" );
        g_free( bla->handle );
        g_free( bla );

Fun fact, I couldn't resist looking: This bug has been in since jabber presence auth was first implemented. (It applies only to Jabber, not other IM networks.)

comment:11 Changed at 2014-02-13T13:10:11Z by wilmer

YEp, it has been. I consider myself shamed, especially since I *think* when this was first reported I blamed gtalk for not implementing authorisation properly.

Which in hindsight, I shouldn't have done so quickly, though OTOH on OSCAR this is how things worked as a "no" would just be visible to the spammer as a sign of life on the account.

comment:12 Changed at 2014-02-13T15:56:48Z by dx

Yeah, uh, #1112.

Don't tell the people at ticket #887 (reported two years ago, same issue as this one) that the fix was so trivial, they are going to be mad.


comment:13 Changed at 2014-03-01T02:10:48Z by dx

Resolution: fixed
Status: newclosed

Patch from ticket #1112 applied in r1012!

Modify Ticket

as closed The owner will remain wilmer.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.