|Summary:||Message from Facebook Chat when it disconnects you for signing in from a new location doesn't reach the UI|
|Product:||Telepathy||Reporter:||Sjoerd Simons <sjoerd>|
|Component:||gabble||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||RESOLVED WONTFIX||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
|Bug Depends on:||70489|
|Attachments:||snapshot of the login sequence|
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 'firstname.lastname@example.org', 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 'email@example.com', 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.