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 support for Vkontakte. Why not, because there are a lot of Vkontakte users and finally with “likes” from this social network. Networks can do something useful for work.



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



About the reasons and the fact that Vkontakte API has a disadvantage, read on.

OAuth, OAuth2 and others

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

')

For those who are not familiar with the essence of the OAuth2 protocol, it means that you register a client application, which can be authorized by the user and via callbacks to the server, so-called is first issued. code that “exchanges” for the access token is access_token .



Possessing 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 “collectors” can correctly calculate the time of the next requester avoiding banning.



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

Methods and likes

The next thing you had to do was find the methods that allow you to get custom likes.



Unlike all other APIs that are supported by us and usually have one method, such as /favorites , /likes , etc. Vkontakte had 5 of them (favorite users , photos , posts , videos and links ). Making 5 requests instead of one seemed not the best idea for productivity, more answers of different methods had a very different format, which slightly fell out of the general collector architecture.



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



Nevertheless, the methods were - all the rest is a matter of technology.

Application registration and first request

I registered the first test Standalone application and soon I had access_token in my hands. Everything went according to the old, knurled pattern. The case remained behind the code that makes HTTP request and parses the result (connector).



But what was my disappointment when in the console instead of the 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 reference code, but after revising the request code and URL of the request 10 times, I understood that everything was fine. Google gave very little information on this issue ... I did not see the error specification in the documentation, and the search results led to ancient forums, in which there was no answer.



I was once again alarmed by this warning:



But the access rights were correct and the application I recognized was Standalone.



Opening my eyes wide and carefully reading the documentation for Standalone applications, I saw that they only support client authorization!



The difference with the server is that the token is passed as response_type , and there is no step with the “exchange” code for access_token, because the callback immediately contains the access_token passed as a hash parameter, i.e. accessible only from the client and not accessible from the server. Since both are called OAuth2, I did not immediately notice this difference.



The lion's share of API methods VK, available only with client authorization. This discovery put me in a real stupor, why?

And really, why?

What made Vkontakte developers to impose such a restriction, and why is VC the only API that implements it?



Of course, any methods of circumventing this restriction come to mind (for example, read access_token on the client and make AJAX POST to the server and then use it freely). I think that with a productive brainstorm a couple more ideas can be born, i.e. the method doesn’t really protect anything, it only adds a headache to the developers. But all sorts of "workarounds" and "hacks" are not how we would like to build our product.



In spite of all the little things - the problem of server access to the API put an end to support for Vkontakte in Likeastore .



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



I very much hope that Vkontakte will revise the policy regarding web applications or at least open up server access to such information as “likes”.



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