[Pidgin] #15376: XMPP missing spec "see-other-host", wrong redirect.
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!
The most annoying part is that the XMPP plugin that comes with Pidgin does
not implement the XMPP RFC specification for "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
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?
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
3) On the "Advanced" tab, I select "require encryption", as Microsoft
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.
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:
Take special note of the new hostname:
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
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...
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
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>
More information about the Tracker