XMPP protocol support in Mail.Ru Agent and authorization “secrets” on Facebook's XMPP server
We are pleased to announce the release of Mail.Ru Agent version 5.8 for Windows !
The main feature of this version is support for the XMPP (Jabber) protocol , which previously appeared in mobile clients for 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 it possible to exchange IM-messages with users of social networks “Vkontakte” and Facebook, who recently opened a public interface to their internal messaging systems using XMPP. As our experience with Mobile Agent has shown, this is the most frequent case of using an XMPP client.
')
However, despite the “sharpened” social networks, our implementation of the protocol supports most of the 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” supports Vkontakte, Facebook, Google Talk, Yandex.Online and QIP services, but if necessary, you can connect any account (for example, on Jabber.Ru) - you just need to specify the JID (Jabber ID) and password in the settings (The server’s IP address will be automatically determined by the SRV DNS query).
If we talk about the features of the implementation of the XMPP client, then we have encountered the main problems in the area of user authorization. The fact is that XMPP servers on Vkontakte and Facebook authorize users not by usernames, which are used for authorization on web services and represent different email addresses, but by JID of the form idXXXX@vk.com and ALIAS@chat.facebok.com , respectively. This is logical, since in the XMPP protocol the domain in the user's 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. With Facebook everything turned out to be somewhat more complicated. By default, the user doesn’t have any ALIAS at all - and although it can be set in your account settings , in some cases you need to go through SMS authorization to confirm this action (enter the code sent by Facebook as an SMS message). A SMS to Russia Facebook ... does not deliver (at least it was a couple of months ago).
Anyway, the idea of forcing the user to enter some “magic” identifiers in the Mail.Ru Agent settings (which he never encounters in everyday life) seemed to us unsuccessful, so we immediately decided to support XMPP authentication with the same login and password, which are used for authorization on the web.
With Vkontakte everything turned out to be simple - we contacted our colleagues, and they provided us with a simple API returning idXXXX using a “web” login / password. The rest was a matter of technology: you just need to 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. In addition to inconvenient for the user authorization by JID (methods PLAIN and DIGEST-MD5), their XMPP-server also supports SASL-authorization . In theory, the idea is trivial. In the client application, the browser is launched, and the user is authorized in it by his usual login / password. After successful authorization, the server returns a token to the browser to the client, with which (after performing some transformations), authorization is already performed via XMPP. Unfortunately, despite the simplicity of this mechanism, there are several subtleties in it that are documented by Facebook very vague, so we had to study quite a few developer forums and to experiment a lot. :)
We are happy to share the results of this small study with you (in case you ever decide to write your XMPP client for Facebook).
So, first we need to create your application in the "admin" of Facebook .
In addition to the obvious options, you need to disable the Disable Deprecated Auth Methods option in the application settings.
In order to log in via SASL, we need to get an authorization token. The main trick here is to properly form the http request for OAuth authorization. It should look something like this:
client_id here is your application id,
response_type - the data type (in this case, the token), which will be returned by the server in case of successful authorization;
redirect_uri - the URL to which the browser will be redirected after successful authorization, the domain of this URL must match the domain specified in the settings of your application;
scope - the 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 doesn’t need to enter a login / password each time he connects).
In case of successful authorization, the http server redirects the browser to redirect_uri, adding the access_token variable (the authorization token itself) to it 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 it is necessary to establish a connection with the XMPP server and request its authorization using the “proprietary” X-FACEBOOK-PLATFORM method. In response to this request, the server will return a challenge — a string of approximately the following form:
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 is a random number;
method - the parameter with the value copied from the challenge;
nonce - identifier copied from the challenge;
session key - the session key obtained from the token;
v - a certain 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 separators, such as ampersands. The order of the parameters in the line is important, because in the next step we calculate md5 from this line and form a new line of the form:
where all parameters are similar to the previous line, and sig - md5 () from it. Here the parameters are already shared by an ampersand.
The resulting string is encoded using the base64 method and authenticate with this data on the XMPP server:
Voila, we are logged in to the XMPP server and can exchange messages with it.
The disadvantage of OAuth / SASL authorization is the actual impossibility of its implementation on mobile clients for platforms such as J2ME and Symbian, since the APIs of these operating systems do not provide the user application with direct access to the browser (through which an 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 (Jabber) protocol , which previously appeared in mobile clients for 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 it possible to exchange IM-messages with users of social networks “Vkontakte” and Facebook, who recently opened a public interface to their internal messaging systems using XMPP. As our experience with Mobile Agent has shown, this is the most frequent case of using an XMPP client.
')
However, despite the “sharpened” social networks, our implementation of the protocol supports most of the 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” supports Vkontakte, Facebook, Google Talk, Yandex.Online and QIP services, but if necessary, you can connect any account (for example, on Jabber.Ru) - you just need to specify the JID (Jabber ID) and password in the settings (The server’s IP address will be automatically determined by the SRV DNS query).
If we talk about the features of the implementation of the XMPP client, then we have encountered the main problems in the area of user authorization. The fact is that XMPP servers on Vkontakte and Facebook authorize users not by usernames, which are used for authorization on web services and represent different email addresses, but by JID of the form idXXXX@vk.com and ALIAS@chat.facebok.com , respectively. This is logical, since in the XMPP protocol the domain in the user's 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. With Facebook everything turned out to be somewhat more complicated. By default, the user doesn’t have any ALIAS at all - and although it can be set in your account settings , in some cases you need to go through SMS authorization to confirm this action (enter the code sent by Facebook as an SMS message). A SMS to Russia Facebook ... does not deliver (at least it was a couple of months ago).
Anyway, the idea of forcing the user to enter some “magic” identifiers in the Mail.Ru Agent settings (which he never encounters in everyday life) seemed to us unsuccessful, so we immediately decided to support XMPP authentication with the same login and password, which are used for authorization on the web.
With Vkontakte everything turned out to be simple - we contacted our colleagues, and they provided us with a simple API returning idXXXX using a “web” login / password. The rest was a matter of technology: you just need to 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. In addition to inconvenient for the user authorization by JID (methods PLAIN and DIGEST-MD5), their XMPP-server also supports SASL-authorization . In theory, the idea is trivial. In the client application, the browser is launched, and the user is authorized in it by his usual login / password. After successful authorization, the server returns a token to the browser to the client, with which (after performing some transformations), authorization is already performed via XMPP. Unfortunately, despite the simplicity of this mechanism, there are several subtleties in it that are documented by Facebook very vague, so we had to study quite a few developer forums and to experiment a lot. :)
We are happy to share the results of this small study with you (in case you ever decide to write your XMPP client for Facebook).
So, first we need to create your application in the "admin" of Facebook .
In addition to the obvious options, you need to disable the Disable Deprecated Auth Methods option in the application settings.
In order to log in via SASL, we need to get an authorization token. The main trick here is to properly form 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 your application id,
response_type - the data type (in this case, the token), which will be returned by the server in case of successful authorization;
redirect_uri - the URL to which the browser will be redirected after successful authorization, the domain of this URL must match the domain specified in the settings of your application;
scope - the 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 doesn’t need to enter a login / password each time he connects).
In case of successful authorization, the http server redirects the browser to redirect_uri, adding the access_token variable (the authorization token itself) to it 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 it is necessary to establish a connection with the XMPP server and request its authorization using the “proprietary” X-FACEBOOK-PLATFORM method. In response to this request, the server will return a challenge — a string of approximately the following form:
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.02b613865ef9e9f742caac8d163da3631where api_key is the API key of your application (not to be confused with the application ID);
call_id is a random number;
method - the parameter with the value copied from the challenge;
nonce - identifier copied from the challenge;
session key - the session key obtained from the token;
v - a certain 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 separators, such as ampersands. The order of the parameters in the 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 parameters are similar to the previous line, and sig - md5 () from it. Here the parameters are already shared by an ampersand.
The resulting string is encoded using the base64 method and authenticate with this data on the XMPP server:
<Response xmlns = "urn: ietf: params: xml: ns: xmpp-sasl"> YXBpX2tleT0zMjEmY2FsbF9pZD00MDc4MDg4NTkmbWV0aG9kPWF1dGgueG1wcF9sb2dpbiZub25jZT04NTlGMkY0Q0QwRjZCMjQ1QTIyRUI2MzgyRDk2ODlEQiAmc2Vzc2lvbl9rZXk9MTlkOGM0ZmNkOTI5ZDEzMjRjZTllZDVmLjEtMTAwMDAxNjg1MTE2YTczICZzaWc9IGRhMGY4ZjAzNjNhOWY3ZTFjYjQ3OWZjZDg4ZjEwNzE2JnY9MS4w </ response>
Voila, we are logged in to the XMPP server and can exchange messages with it.
The disadvantage of OAuth / SASL authorization is the actual impossibility of its implementation on mobile clients for platforms such as J2ME and Symbian, since the APIs of these operating systems do not provide the user application with direct access to the browser (through which an 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
Source: https://habr.com/ru/post/118981/
All Articles