Bug 297994 - Contact subscription requests re-appear after reconnect
Summary: Contact subscription requests re-appear after reconnect
Status: RESOLVED FIXED
Alias: None
Product: telepathy
Classification: Unclassified
Component: kded-module (show other bugs)
Version: 0.4.1
Platform: Chakra Linux
: NOR normal
Target Milestone: Future
Assignee: Telepathy Bugs
URL:
Keywords:
: 298765 302438 325326 327640 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-12 19:50 UTC by Venky
Modified: 2013-12-29 14:52 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 0.7.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Venky 2012-04-12 19:50:05 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20100101 Firefox/12.0
Build Identifier: 

When I login into telepathy with my yahoo protocol, I constantly get spam accounts trying to add me, or wanting permission to see my visibility. There is no way to block those users, the only option is to deny the request, but it appears again in next re-connect.

Reproducible: Always

Steps to Reproduce:
1.login into kde telepathy yahoo account which gets spam requests
2. add/view visibility requests should pop up in system tray
3. deny requests (no blocking capability) 



Expected Results:  
ability to block the users for ever
Comment 1 Martin Klapetek 2012-04-21 12:51:52 UTC
The current implementation of adding contacts is broken somewhere upstream (the problem with repeated request) - everytime you deny any request, it reappears on next login. So it's most probably not the spammers trying to add you again and again, but rather a bug (see bug 290634).

However we could still have an option to block those users (so new request -> Accept | Deny | Block), but I'm unsure if Telepathy supports blocking of users not in your roster...
Comment 2 David Edmundson 2012-04-21 15:40:30 UTC
I remember Olli Salli telling us that would happen (two years ago at our first sprint). He seemed to imply that it's up to us to remember what we asked the user, but then when I tested denying a user it worked fine, so I thought they must have changed it.

If you haven't talked to upstream yet, do so.
Comment 3 Martin Klapetek 2012-04-24 20:32:26 UTC
*** Bug 298765 has been marked as a duplicate of this bug. ***
Comment 4 David Edmundson 2012-06-24 11:58:00 UTC
*** Bug 302438 has been marked as a duplicate of this bug. ***
Comment 5 David Edmundson 2012-06-24 13:33:24 UTC
Been looking at what's been going on:

 - we call removePresencePublication (in TpQt)
 - this has the code:

if (usingFallbackContactList) {
  remove contact from group
} else {
  call "Unpublish" [1]
}

[1]http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_List.html#Method:Unpublish

I have no idea what a fallbackcontactlist is.. we should see if haze is that.
A quick grep of Empathy shows it never calls unpublish, despite this method existing tp-glib. Maybe they have a wrapper that does something else?
Comment 6 George Kiagiadakis 2012-06-24 13:50:06 UTC
(In reply to comment #5)
> I have no idea what a fallbackcontactlist is.. we should see if haze is that.
> A quick grep of Empathy shows it never calls unpublish, despite this method
> existing tp-glib. Maybe they have a wrapper that does something else?

Contact lists can be exposed in two ways. The old way is to spawn a special channel of type ContactList (deprecated), which exposes the contacts using the Group interface of the channel. The new way is to use Conn.I.ContactList. Tp-Qt internally handles both types of contact lists. In this case, fallbackcontactlist means the old Channel.Type.ContactList. I expect tp-glib to have a similar abstraction mechanism.

By running qdbus on haze, it looks like it is still using Channel.Type.ContactList. Not sure if this can cause trouble, though. I think this behavior is normal if the server doesn't store the user's choice.
Comment 7 David Edmundson 2012-06-24 14:36:04 UTC
Thanks George.
So it's taking a different but valid path, though clearly we (KTp or TpQt) aren't doing something quite right.

Tasks (for anyone):
 - check everything does work in Empathy, and if running empathy once stops it appearing for us each time.
 - find out what Empathy does
 - find out what tp-glib does
 - fix it :D
Comment 8 David Edmundson 2013-10-07 16:36:16 UTC
*** Bug 325326 has been marked as a duplicate of this bug. ***
Comment 9 Martin Klapetek 2013-11-15 09:10:59 UTC
*** Bug 327640 has been marked as a duplicate of this bug. ***
Comment 10 James Choa 2013-12-16 01:47:02 UTC
I don't have the time yet to check what Empathy and tp-glib does, but I can confirm that blocking the contact from Empathy will stop the subscription request from re-appearing after reconnect.
Comment 11 David Edmundson 2013-12-29 14:52:06 UTC
Git commit 13b81af5cc8f79cbd4edd77dddd020078afec7fb by David Edmundson.
Committed on 26/12/2013 at 15:06.
Pushed by davidedmundson into branch 'kde-telepathy-0.7'.

Block contacts when denying requests

This prevents them from reappearing
REVIEW: 114671
FIXED-IN: 0.7.1

M  +9    -2    contact-request-handler.cpp

http://commits.kde.org/telepathy-kded-module/13b81af5cc8f79cbd4edd77dddd020078afec7fb