[Pidgin] #15376: XMPP missing spec "see-other-host", wrong redirect.

Pidgin trac at pidgin.im
Wed Oct 24 14:40:53 EDT 2012


#15376: XMPP missing spec "see-other-host", wrong redirect.
------------------------+--------------------
 Reporter:  eduncan911  |      Owner:  deryni
     Type:  defect      |     Status:  new
Milestone:              |  Component:  XMPP
  Version:  2.10.6      |   Keywords:
------------------------+--------------------
 So, I was able to connect to Microsoft's "XMPP" server today.  It was a
 bit tricky, but works.

 But my "AUTH TOKEN" is sent directly to pidgin.im in the querystring!  So,
 technically, anyone reading the web logs of pidgin.im now has a temp auth
 token to gain access to my Microsoft messenger account. NOT GOOD!

 '''Issue 1:'''
 The most annoying part is that the XMPP plugin that comes with Pidgin does
 not implement the XMPP RFC specification for "see-other-host".

 http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-see-other-host

 Microsoft requires this implementation, as of April 2012 (they previously
 did not require it when they first launched XMPP support in December
 2011):

 http://msdn.microsoft.com/en-us/library/live/hh826554.aspx


 '''Issue 2:'''
 After successful OAUTH2 authentication on Microsoft's servers, I am
 redirected to pidgin.im, with my entire AUTH TOKEN in the querystring!


 '''How to connect via XMPP to Microsoft Account's Messenger:'''

 So, how was I able to connect?

 To prepare:

 1) Enable the two plugins "XMPP" and "XMPP Console".
 2) Goto Tools -> XMPP Console and open it.  You will need the "see-other-
 host" down below.


 '''To configure the XMPP plugin:'''

 1) Enable the XMPP plugin.

 2) For "Username" and "Domain", the microsoft link above states:

 {{{
 "The Messenger XMPP service uses the user ID in the access token to sign
 the user in and to bind the user to the session. To do this, Jabber IDs
 that are assigned by the Messenger XMPP service use the format
 identifier at messenger.live.com instead of a Microsoft account user ID."
 }}}

 Let's pretend that my Microosft Account is xyz123 at msn.com.

 So for my '''Username''', I entered "xyz123", and for the '''Domain''', I
 entered "messenger.live.com".  I have completely omitted my "msn.com",
 which you will see below why that is (it doesn't matter, see the OAUTH2
 portion below).

 3) On the "Advanced" tab, I select "require encryption", as Microsoft
 requires it.

 Connect port: 5222
 Connect server: xmpp.messenger.live.com (NOTE: this changes, see below)

 And I left everything else default, including "File transfer proxies" set
 to proxy.eu.jabber.org, though that doesn't work yet.

 4) Once you save and it attempts to connect, you'll be asked to accept an
 SSL certification.  Click yes.



 '''"see-other-host" requirement'''

 Now, your XMPP Console should be chatty, and disconnected.  This is
 because the XMPP plugin does not support the "see-other-host"
 specification, and therefore disconnects.

 Scroll through the console and look for this:

 {{{
 <error xmlns='http://etherx.jabber.org/streams'>
   <see-other-host xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
     SN1MSG3030112.gateway.messenger.live.com
   </see-other-host>
 </error>
 }}}

 Take special note of the new hostname:

 {{{
 SN1MSG3030112.gateway.messenger.live.com
 }}}

 This will change very often, as things often do on Microsoft gateways.
 This is why the "see-other-host" needs to be implemented.

 Now, go back in and Edit your XMPP plugin, click Advanced, and paste that
 entire "SN1MSG3030112.gateway.messenger.live.com" into the "Connect
 server:" textbox.  Leave the Connect port 5222 the same.

 Pidgin connects and now...


 '''Logging In with OAUTH2 and redirecting, with "see-other-host".'''

 Now, a browser windows pops open asking me to log into my Microsoft
 Account.  Yay, OAUTH2 working!  I login, and immediately get redirected
 to:

 pidgin.im?token=#####################################################################################

 Yes, it actually passes my entire auth token directly to pidgin.im in the
 querystring.  I'm not too happy about that.  Not good!  It would seem the
 XMPP OAUTH2 plugin handling needs to be directed to a page to display this
 to the user in a friendly manner, so they can easily copy-and-paste it.


 '''New popup, "Enter authorization token"'''

 You will need to highlight the ENTIRE auth token in the querystring in the
 browser, after the "=" portion, and copy it to clipboard.  Because now,
 that is your auth token.

 Switching back to Pidgin, it now asks you for that token in a popup.
 Paste that entire auth token, and...

 drumroll...

 I'm connected!


 It would seem this can all be fixed by fixing two key RFC components:

 1) "see-other-host" support, as linked to above.

 2) Enabling better OAUTH2 token handling support.  Maybe a new page on
 Pidgin that displays it to the user, so they can copy-n-paste it from a
 textbox.  But I think the OAUTH2 protocol supports "API" or "Application"
 specification in the OAUTH2 request, allowing for the token to be passed
 back via the original request - instead of a browser window.

 Maybe even iframe it, and capture it on the redirect URL as the token to
 use (that's how I did it for other desktop applications, and on Windows
 Phone).


 Please consider this as two work items to achieve XMPP support for
 Microsoft servers, as it is currently a PITA!

-- 
Ticket URL: <https://developer.pidgin.im/ticket/15376>
Pidgin <http://pidgin.im>
Pidgin


More information about the Tracker mailing list