Bug 37376 - Provide a pseudo-mechanism for vendor-specific SASL mechanisms
Provide a pseudo-mechanism for vendor-specific SASL mechanisms
Status: NEW
Product: Telepathy
Classification: Unclassified
Component: gabble
git master
Other All
: medium normal
Assigned To: Telepathy bugs list
Telepathy bugs list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-19 09:22 UTC by Will Thompson
Modified: 2012-10-01 12:12 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Thompson 2011-05-19 09:22:56 UTC
I think Gabble (or Wocky, for that matter) should carry its own implementations of X-GOOGLE-TOKEN and X-FACEBOOK-PLATFORM, and expose them when appropriate as a pseudo-mechanism (X-TELEPATHY-OAUTH-TOKEN, say) which takes the token as initial data.

This obviously doesn't mean that it shouldn't also offer the real mechanisms too. But there's no reason why everyone who wants to do Facebook or Google integration should have to re-implement these XMPP-specific mechanisms: they should live in the XMPP component. And, if AIM or something switches to OAuth authentication, Haze or whatever could implement this pseudo-mech and all would be sweetness and light.

For a motivating example: GNOME Online Accounts provides methods to get an OAuth or OAuth2 (as appropriate) token for an account. It would be nice if the inevitable auth channel handler for GOA-based accounts didn't have to implement these mechanisms, and it would also be nice to not have to bake them into GOA (which would otherwise contain no XMPP-specific code), leaving Gabble as the only remaining home :)

I guess we'd have to split OAuth1 and OAuth2.
Comment 1 Will Thompson 2011-05-19 09:51:33 UTC
BTW:

• off the top of my head, X-GOOGLE-TOKEN is essentially PLAIN but with an OAuth token rather than the password (i.e. sha1('\0' + username + '\0' + token);
• X-FACEBOOK-PLATFORM is slightly more involved, but the only external information the XMPP client needs is still just an OAuth 2 token, so the pseudo-mechanism I describe above could be implemented: <https://developers.facebook.com/docs/chat/>.
Comment 2 Will Thompson 2011-05-20 06:37:43 UTC
This implies that Gabble would have to contain a Facebook API key. Perhaps there could be a hook to allow an alternative API key to be provided by distributors without patching Gabble itself.
Comment 3 Guillaume Desmottes 2011-09-07 02:04:41 UTC
For the record, https://bugzilla.gnome.org/show_bug.cgi?id=652546 and https://bugzilla.gnome.org/show_bug.cgi?id=652544 are the empathy bugs about Google and Facebook SSO support.
Comment 4 Xavier Claessens 2012-10-01 12:10:03 UTC
(In reply to comment #1)
> • X-FACEBOOK-PLATFORM is slightly more involved, but the only external
> information the XMPP client needs is still just an OAuth 2 token, so the
> pseudo-mechanism I describe above could be implemented:
> <https://developers.facebook.com/docs/chat/>.

Did not check latest doc, but empathy's code also uses the client-id of the app.
Comment 5 Xavier Claessens 2012-10-01 12:12:29 UTC
(In reply to comment #4)
> (In reply to comment #1)
> > • X-FACEBOOK-PLATFORM is slightly more involved, but the only external
> > information the XMPP client needs is still just an OAuth 2 token, so the
> > pseudo-mechanism I describe above could be implemented:
> > <https://developers.facebook.com/docs/chat/>.
> 
> Did not check latest doc, but empathy's code also uses the client-id of the
> app.

well, if I read everything, I see you pointed that out already :-)

Note that API key depends on the account storage! We have GOA and UOA atm...