Bug 26696 - Message from Facebook Chat when it disconnects you for signing in from a new location doesn't reach the UI
Summary: Message from Facebook Chat when it disconnects you for signing in from a new ...
Status: RESOLVED WONTFIX
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: 0.8
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on: 70489
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-22 05:38 UTC by Sjoerd Simons
Modified: 2016-07-13 10:13 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
snapshot of the login sequence (2.57 KB, text/plain)
2010-02-22 05:38 UTC, Sjoerd Simons
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sjoerd Simons 2010-02-22 05:38:43 UTC
Created attachment 33490 [details]
snapshot of the login sequence

facebook has some kind of security where it blocks you logging in over xmpp if you login from a new network location (?). They do this blocking by sending a <message /> immediately after the session starts and send a stream error directly after that... This doesn't bubble up to the UI apart from as a login error or even a message (it gets disconnected before the channel gets dispatched?). So the user just sees ``Network error'' or ``Name in use''..
Comment 1 Will Thompson 2010-03-19 07:43:52 UTC
So, what's happening is that it accepts our credentials, but immediately sends us a <message/> from 'chat.facebook.com' explaining the situation, and then disconnects us. However, the message never makes it to the UI, for two reasons:

• The message sender's JID is just a domain, not node@domain. Gabble currently
ignores messages from such JIDs. This is buggy; however, the flipside of
allowing IMing such JIDs is that if the user types 'foo.bar' rather than
'foo.bar@gmail.com', Gabble would happily try to communicate with the domain
foo.bar rather than raising an error as it currently does.

• Even if Gabble did expose the message, since the connection is immediately
terminated the channel would die before it has a chance to make it to the UI.

We should fix both of these issues. The former is just a Gabble issue; the
later needs work in the spec. and MC...
Comment 2 Will Thompson 2010-03-30 11:28:57 UTC
Spec meeting notes:

First problem: Gabble doesn't think chat.facebook.com is a valid handle.

• Should Gabble let you request a handle for JIDs with no node part? If
  so, then if you mistakenly try to contact 'will.thompson' rather than
  'will.thompson@collabora.co.uk', the failure will occur much later
  than it currently does (since at the moment Gabble won't give you a
  handle, or a channel, for the former).
• Idle is a bit more tolerant of contact IDs it receives from the
  network than those it receives over D-Bus, because bip uses a nickname
  that's illegal per the IRC RFC. This would be an acceptable stop-gap
  solution in Gabble, too.

Second problem: what do we do about channels appearing as the connection
closes?

• this could be a property of the disconnecting state in hypothetical
  Telepathy 1.0?
• add a flag for "i'm well behaved, i'll close up my own channels"
  · problem: then you have to ack all the messages before you can
    reconnect
  · here's a bad idea: uniquify channel paths across connections, make
    channel outlive connection. rejected: you need the connection to
    look up aliases and do other useful things with a channel.
  · here's another bad idea: re-use connections, rather than having them
    die when they become Disconnected.
• we punted on this for now.
Comment 3 Will Thompson 2010-05-14 08:18:00 UTC
The recent discussion about Captcha channels led me to wonder... maybe we could introduce a new channel type for server messages/notifications. That is, messages like these messages from the Facebook server, from IRC servers, and so on, which should be displayed to the user but to which the user has no way (or limited ways) to respond. (Sending normal text messages to servers on XMPP makes sense in some pretty restricted cases, though...)

If we were to introduce a new channel type, then having the connection stay open until they're closed would not break backwards compat.: either you have a handler — in which case it can ack messages/close the channel/etc. — or you don't — in which case the channel will be Close()d by MC in a huff.
Comment 4 Will Thompson 2010-11-20 03:23:35 UTC
We could hack the Facebook case by having Gabble save the message chat.facebook.com sends us (either by hard-coding that JID in Gabble, or by looking at the domain part of our JID). Then if the very next thing that happens is we get disconnected, we could put the message into ConnectionError, along with a d-bus error code which means “the server sent us a message and then booted us off”.

This obviously doesn't solve the general case of the user missing messages that arrive just as they're disconnecting (a distressing case, to be sure) but would make for a nicer experience in the Facebook case.
Comment 5 Guillaume Desmottes 2013-01-04 10:38:27 UTC
Empathy user hitting this bug (with logs): https://bugzilla.gnome.org/show_bug.cgi?id=686403
Comment 6 George Kiagiadakis 2016-07-13 10:13:34 UTC
Afaik, facebook no longer supports XMPP, so I'm closing this report. The underlying issues may still appear with another service, but let's deal with that when it actually happens.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.