Why we do not have VKontakte support

    After our first announcement on Habré, many new users from Russia came to us and one of the most frequently requested features was Vkontakte support. Why not, because there are a lot of Vkontakte network users and finally with “likes” from this social network. Networking can do something useful for work.

    We have already gained decent experience integrating with various APIs: Twitter, Facebook, Github, Behance, etc. plus, we already had a certain boilerplate code, with the help of which new integrations are done in the shortest possible time. Having set a goal to please our users this week, I am forced to admit that this turned out to be an impossible task.

    Read about the reasons and the disadvantage of the Vkontakte API.

    OAuth, OAuth2 and others

    The first thing I look at in the documentation for the new service is the type of authorization. OAuth2 has become the default standard at the moment and many Likeastore- supported services implement it (the only difference is Twitter, which implements OAuth1 and Dribbble, which does not implement the protocol at all, but only supports the grandfather login / password protocol).

    For those who are not familiar with the essence of the OAuth2 protocol, you register a client application that can be authorized by the user and through callbacks to the server, the so-called first one is published. code, which is "exchanged" for an access token - access_token.

    With an access token, the application is able to make requests on behalf of the user. This is very convenient, since all popular APIs have a number of restrictions (the so-called rate limit) and knowing the number of allowed requests per unit of time, the component responsible for collecting “likes” can correctly calculate the time of the next request avoiding going to the ban.

    I was glad to see that Vkontakte supports exactly the OAuth2 protocol.

    Methods and likes

    The next thing to find was methods that allow you to get custom “likes”.

    Unlike all other APIs that are supported by us and usually have one method, type /favorites, /likesetc. Vkontakte had 5 of them (favorite users , photos , posts , videos and links ). Doing 5 requests instead of one didn’t seem to be the best idea for performance, more answers from different methods had a very different format, which fell out of the general collector architecture a bit.

    Later I noticed that VK offers the so-called "Stored procedures", in which you can collect all the necessary data and return it in one HTTP request. It is a working solution, but after experience with Facebook API batching seemed to me not so elegant.

    However, the methods were - everything else is a matter of technology.

    Application registration and first request

    I registered the first test Standalone application and soon was in my hands access_token. Everything went according to the old pattern. It was up to the code that makes the HTTP request and parses the result (connector).

    But, what was my disappointment when, in the console, instead of data, I saw the following answer.

    { error:
       { error_code: 5,
         error_msg: 'User authorization failed: method is unavailable with server auth.',
         request_params: [ [Object], [Object], [Object], [Object], [Object] ] } }

    At first it seemed to me that something was wrong with the API access code but after 10 times reviewing the code and the request URL, I realized that everything was fine. Google on this issue gave very little information ... in the documentation I did not see the specification of the error, and the search results led to ancient forums, in which there was no answer.

    I was again warned by this warning:
    But the access rights were correct and the application I realized was Standalone.

    Having opened my eyes wider and carefully read the documentation on Standalone applications, I saw that they only support client authentication!
    The difference with the server one is that the response_typevalue is passed astoken, and there is no step with “exchanging” code for access_token, since the access_token passed as a hash parameter is immediately present in the callback, i.e. accessible only from the client and not accessible from the server. Because both of them are called OAuth2, I did not immediately pay attention to this difference.

    The lion's share of VC API methods are available only with client authorization. This discovery led me into a real stupor, why?

    And really, why?

    What made Vkontakte developers introduce such a restriction, and why is VK the only API that implements it?

    Of course, all sorts of methods to circumvent this restriction come to mind (for example, to read access_token on the client and make an AJAX POST to the server, and after that it is free to use it). I think that with a productive brainstorm a couple more ideas may be born, i.e. the method does not really protect anything, but only adds a headache to developers. But all kinds of “rounds” and “hacks” are not how we would like to build our product.

    Despite all the little things - it was the problem of server access to the API that put an end to Vkontakte support in Likeastore .

    Threat. The primary goal of this post was to appeal to users, as well as the community, asking for help with advice from those who may have been in a similar situation. Already in the process of writing, I found a wonderful kimrgrey post that describes the same problem , as well as an antanubis answer that explains why this is done in this way. His argument is very clear, as for me, not so convincing.

    I really hope that Vkontakte will review its policy regarding web applications or at least open server access to such information as “likes”.

    ZYY. Another option might be to use Direct Authorization., but personally, I would never enter my VK password on another site + approval of the administration is required, which can not be obtained or it will take a lot of time. But if someone used this method, I would be glad to hear the experience.

    Also popular now: