XMPP protocol support in Mail.Ru Agent and “secrets” of authorization on Facebook's XMPP server
We are pleased to inform you about the release of Mail.Ru Agent version 5.8 for Windows !
The main "feature" of this version is support for the XMPP protocol (Jabber) , which previously appeared in mobile clients for the Symbian and Java 2 Micro Edition platforms. Since the most active and technically “advanced” part of our audience uses mobile messaging, we started the experiment with XMPP from mobile platforms. However, the "feature" unexpectedly turned out to be quite popular and in demand, including on the desktop.
The main idea of supporting this protocol is to make possible the exchange of IM messages with users of the social networks Vkontakte and Facebook, who recently opened a public interface to their internal messaging systems using the XMPP protocol. As our experience with the Mobile Agent has shown, this is the most common case of using an XMPP client.
However, despite the “imprisonment” for social networks, our protocol implementation supports most popular extensions (XEPs - XMPP Extenstion Protocol), so Mail.Ru Agent can be used as a client to connect to the most arbitrary XMPP servers. Out of the box Vkontakte, Facebook, Google Talk, Yandex.Online and QIP services are supported, however, if necessary, you can connect any account (for example, on Jabber.Ru) - just specify the JID (Jabber ID) and password in the settings (The server's IP address will be determined automatically by the SRV-request to DNS).
If we talk about the features of the implementation of the XMPP client, we faced the main problems in the field of user authorization. The fact is that the Vkontakte and Facebook XMPP servers do not authorize users by logins that are used to authorize on web services and represent different addresses email, and by JID of the form idXXXX@vk.com and ALIAS@chat.facebok.com , respectively. This is logical because in the XMPP protocol, the domain in the user JID must match the domain of the XMPP server to which this JID belongs.
In the case of VKontakte, idXXXX is some internal user identifier that can be viewed, for example, in the URL of your profile. C Facebook was a little more complicated. By default, the user does not have any ALIAS at all - and although it can be set in the settings of your account , in some cases you need to go through SMS authorization to confirm this action (enter the code sent by Facebook as an SMS message). And Facebook ... doesn’t deliver SMS to Russia (in any case, it was a couple of months ago).
One way or another, the idea of forcing the user to enter some “magic” identifiers (which he never encounters in everyday life) in Mail.Ru Agent settings seemed to us unsuccessful, so we immediately decided to support authorization in XMPP with the same login and password, which are used for authorization on the web.
Everything turned out to be simple with VKontakte - we contacted our colleagues and they provided us with a simple API that returns idXXXX with a "web" login / password. Further, it was a technical matter: just take idXXXX and the password specified by the user in the Mail.Ru Agent settings and log in to the XMPP server using the standard DIGEST-MD5 method .
Facebook made us tinker. Besides inconvenient for the user JID authorization (using PLAIN and DIGEST-MD5 methods), their XMPP server also supports SASL authentication . In theory, the idea is trivial. A browser is launched in the client application, and in it the user logs in using his usual login / password. After successful authorization, the server returns a token to the client browser, with which (after some conversions are completed) XMPP authentication is already performed. Unfortunately, despite the simplicity of this mechanism, it has several subtleties that Facebook has documented very vaguely, so we had to study a lot of development forums and experiment a lot. :)
We are pleased to share the results of this small study with you (in case you ever decide to write your XMPP client for Facebook).
So, for starters, we need to create our own application in the Facebook admin panel .
In addition to the obvious options, in the application settings you need to disable the option " Disable Deprecated Auth Methods ".
In order to log in through SASL, we need to get an authorization token. The main trick here is to correctly configure the http request for OAuth authorization. It should look something like this:
client_id here is the id of your application,
response_type- the type of data (in this case, the token) that the server will return in case of successful authorization;
redirect_uri - URL to which the browser will be redirected after successful authorization, the domain of this URL must necessarily coincide with the domain specified in the settings of your application;
scope - requested access rights. The xmpp_login option allows you to use the received authorization token for SASL authorization on the XMPP server, and offline_access provides this token with an “eternal” lifetime (so that the user does not need to enter a login / password each time it is connected).
In case of successful authorization, the http server redirects the browser to redirect_uri, adding the access_token variable (in fact, the authorization token) as a GET parameter. The value of this variable is a string divided into three parts by the symbol “|”:
We are interested in the middle part - the session key.
Now you need to establish a connection with the XMPP server and request authorization from it using the “proprietary” X-FACEBOOK-PLATFORM method . In response to this request, the server will return a challenge - a line of something like this:
Next, we form something like this:
where api_key is the API key of your application (not to be confused with the application ID);
call_id - random number;
method- a parameter with a value copied from challenge;
nonce - identifier copied from challenge;
session key - session key obtained from the token;
v - some version number (Facebook recommends using 1.0).
The value after the version number (2b613865ef9e9f742caac8d163da3631) corresponds to the secret key of your application (not to be confused with the API key and application ID).
Note that the parameters in this line follow without any delimiters, such as ampersands. The sequence of parameters in a line is important, because in the next step we calculate md5 from this line and form a new line of the form:
where all the parameters are similar to the previous line, and sig is md5 () from it. Here the parameters are already shared by an ampersand.
The resulting string is encoded with the base64 method and logged in with this data on the XMPP server:
Voila, we are authorized on the XMPP server and we can exchange messages with it.
The disadvantage of OAuth / SASL authentication is the fact that it cannot be implemented on mobile clients for platforms such as J2ME and Symbian, since the APIs of these OSs do not provide the user application with direct access to the browser (through which the authorization token is obtained).
We invite everyone to try Mail.Ru Agent 5.8 and especially look forward to impressions about the work of our XMPP client.
Ilya Naumov,
Project Manager Mail.Ru Agent
The main "feature" of this version is support for the XMPP protocol (Jabber) , which previously appeared in mobile clients for the Symbian and Java 2 Micro Edition platforms. Since the most active and technically “advanced” part of our audience uses mobile messaging, we started the experiment with XMPP from mobile platforms. However, the "feature" unexpectedly turned out to be quite popular and in demand, including on the desktop.
The main idea of supporting this protocol is to make possible the exchange of IM messages with users of the social networks Vkontakte and Facebook, who recently opened a public interface to their internal messaging systems using the XMPP protocol. As our experience with the Mobile Agent has shown, this is the most common case of using an XMPP client.
However, despite the “imprisonment” for social networks, our protocol implementation supports most popular extensions (XEPs - XMPP Extenstion Protocol), so Mail.Ru Agent can be used as a client to connect to the most arbitrary XMPP servers. Out of the box Vkontakte, Facebook, Google Talk, Yandex.Online and QIP services are supported, however, if necessary, you can connect any account (for example, on Jabber.Ru) - just specify the JID (Jabber ID) and password in the settings (The server's IP address will be determined automatically by the SRV-request to DNS).
If we talk about the features of the implementation of the XMPP client, we faced the main problems in the field of user authorization. The fact is that the Vkontakte and Facebook XMPP servers do not authorize users by logins that are used to authorize on web services and represent different addresses email, and by JID of the form idXXXX@vk.com and ALIAS@chat.facebok.com , respectively. This is logical because in the XMPP protocol, the domain in the user JID must match the domain of the XMPP server to which this JID belongs.
In the case of VKontakte, idXXXX is some internal user identifier that can be viewed, for example, in the URL of your profile. C Facebook was a little more complicated. By default, the user does not have any ALIAS at all - and although it can be set in the settings of your account , in some cases you need to go through SMS authorization to confirm this action (enter the code sent by Facebook as an SMS message). And Facebook ... doesn’t deliver SMS to Russia (in any case, it was a couple of months ago).
One way or another, the idea of forcing the user to enter some “magic” identifiers (which he never encounters in everyday life) in Mail.Ru Agent settings seemed to us unsuccessful, so we immediately decided to support authorization in XMPP with the same login and password, which are used for authorization on the web.
Everything turned out to be simple with VKontakte - we contacted our colleagues and they provided us with a simple API that returns idXXXX with a "web" login / password. Further, it was a technical matter: just take idXXXX and the password specified by the user in the Mail.Ru Agent settings and log in to the XMPP server using the standard DIGEST-MD5 method .
Facebook made us tinker. Besides inconvenient for the user JID authorization (using PLAIN and DIGEST-MD5 methods), their XMPP server also supports SASL authentication . In theory, the idea is trivial. A browser is launched in the client application, and in it the user logs in using his usual login / password. After successful authorization, the server returns a token to the client browser, with which (after some conversions are completed) XMPP authentication is already performed. Unfortunately, despite the simplicity of this mechanism, it has several subtleties that Facebook has documented very vaguely, so we had to study a lot of development forums and experiment a lot. :)
We are pleased to share the results of this small study with you (in case you ever decide to write your XMPP client for Facebook).
So, for starters, we need to create our own application in the Facebook admin panel .
In addition to the obvious options, in the application settings you need to disable the option " Disable Deprecated Auth Methods ".
In order to log in through SASL, we need to get an authorization token. The main trick here is to correctly configure the http request for OAuth authorization. It should look something like this:
www.facebook.com/dialog/oauth?client_id=123&response_type=token&redirect_uri=http://agent.mail.ru/&display=popup&scope=xmpp_login,offline_accessclient_id here is the id of your application,
response_type- the type of data (in this case, the token) that the server will return in case of successful authorization;
redirect_uri - URL to which the browser will be redirected after successful authorization, the domain of this URL must necessarily coincide with the domain specified in the settings of your application;
scope - requested access rights. The xmpp_login option allows you to use the received authorization token for SASL authorization on the XMPP server, and offline_access provides this token with an “eternal” lifetime (so that the user does not need to enter a login / password each time it is connected).
In case of successful authorization, the http server redirects the browser to redirect_uri, adding the access_token variable (in fact, the authorization token) as a GET parameter. The value of this variable is a string divided into three parts by the symbol “|”:
216315195049043|19d8c4fcd929d1324ce9ed5f.1-100001685116a73|ifwc5qPhOguAhc3vaRmtCBnqv7EWe are interested in the middle part - the session key.
Now you need to establish a connection with the XMPP server and request authorization from it using the “proprietary” X-FACEBOOK-PLATFORM method . In response to this request, the server will return a challenge - a line of something like this:
version=1&method=auth.xmpp_login&nonce=859F2F4CD0F6B245A22EB6382D9689DBNext, we form something like this:
api_key=321call_id=407808859method=auth.xmpp_loginnonce=859F2F4CD0F6B245A22EB6382D9689DB session_key=19d8c4fcd929d1324ce9ed5f.1-100001685116a73v=1.02b613865ef9e9f742caac8d163da3631 where api_key is the API key of your application (not to be confused with the application ID);
call_id - random number;
method- a parameter with a value copied from challenge;
nonce - identifier copied from challenge;
session key - session key obtained from the token;
v - some version number (Facebook recommends using 1.0).
The value after the version number (2b613865ef9e9f742caac8d163da3631) corresponds to the secret key of your application (not to be confused with the API key and application ID).
Note that the parameters in this line follow without any delimiters, such as ampersands. The sequence of parameters in a line is important, because in the next step we calculate md5 from this line and form a new line of the form:
api_key=321&call_id=407808859&method=auth.xmpp_login&nonce=859F2F4CD0F6B245A22EB6382D9689DB&session_key=19d8c4fcd929d1324ce9ed5f.1-100001685116a73&sig=da0f8f0363a9f7e1cb479fcd88f10716&v=1.0where all the parameters are similar to the previous line, and sig is md5 () from it. Here the parameters are already shared by an ampersand.
The resulting string is encoded with the base64 method and logged in with this data on the XMPP server:
YXBpX2tleT0zMjEmY2FsbF9pZD00MDc4MDg4NTkmbWV0aG9kPWF1dGgueG1wcF9sb2dpbiZub25jZT04NTlGMkY0Q0QwRjZCMjQ1QTIyRUI2MzgyRDk2ODlEQiAmc2Vzc2lvbl9rZXk9MTlkOGM0ZmNkOTI5ZDEzMjRjZTllZDVmLjEtMTAwMDAxNjg1MTE2YTczICZzaWc9IGRhMGY4ZjAzNjNhOWY3ZTFjYjQ3OWZjZDg4ZjEwNzE2JnY9MS4w
Voila, we are authorized on the XMPP server and we can exchange messages with it.
The disadvantage of OAuth / SASL authentication is the fact that it cannot be implemented on mobile clients for platforms such as J2ME and Symbian, since the APIs of these OSs do not provide the user application with direct access to the browser (through which the authorization token is obtained).
We invite everyone to try Mail.Ru Agent 5.8 and especially look forward to impressions about the work of our XMPP client.
Ilya Naumov,
Project Manager Mail.Ru Agent