Working with VKontakte Open API in the local development environment
As many know, the authors of the social network VKontakte about two months ago published the Open API, through which third-party sites were able to authenticate users with their VKontakte accounts. The developer documentation describes how to configure the Open API for your production site on a production server. But in real life, development is carried out on local machines with storage of code in the version control system, and updates to production are set periodically.
At the same time, there is a problem: how to test the Open API on local developers' machines, if access to it is configured only for production? In this article, I want to talk about how to set up a local environment to work with the Open API in a standard development cycle. I’ll make a reservation that I’ll consider Windows development using Microsoft technologies, but the idea can be easily transferred to other platforms.
So, the essence of the problem. As stated in the documentation, to configure, you need to create a VKontakte application. It is important to specify the address of your site and the base domain:
When initializing the Open API on your VKontakte site, it will match the application identifier specified in the apiId parameter and the URL of the site on which this initialization is performed. If the URL does not match the parameters entered in the settings of your application (see above), then we will receive an error message: “Open API security breach”. This is a problem because, for example, when developing using Visual Studio, sites are often tested locally using the embedded web server at http: // localhost: port (where port is a number, port number). But at the same time, the Open API stops working for the reasons stated above - on local machines of Vkontakte, it’s not the resolved site address ( http://example.com ), but the local site http: // localhost: port . How to solve this problem?
')
The essence of the solution is quite simple: you need to configure the local environment so that requests to the site address specified in the VKontakte application settings ( http://example.com ) are not forwarded to the Internet-accessible production server via DNS, but to the local site on the machine developer. In this case, the developer will be able to test the Open API, because now his local site will have the address http://example.com allowed from the point of view of VK.
Setup consists of several steps. First of all, you need to edit the windows \ system32 \ drivers \ etc \ hosts file. You need to insert the following entry:
So all requests to example.com will be redirected to the local machine. Now you need to configure a local web server (in our case, IIS 7) to redirect requests to example.com to a local copy of the developer's site. To do this, create a new web site in IIS Manager, configure the physical path to the folder with the site files and specify the following bindings:
And finally, the last step in the event that a proxy is used on the local machine. In the browser settings (in IE, it is Tools> Internet Options> Connections> LAN Settings> Advanced) you need to add example.com to the list of exceptions (Do not use proxy server for meetings beginning).
Several limitations of the described approach: first, developers will not be able to go to the production site from their machines and to the local site at the same time. In order to install on production they will need to change their hosts file (remove the above entry). And secondly, they will be forced to use IIS as a web server during development, abandoning Visual Studio’s embedded web server. But as practice shows, the last limitation is rather a plus, since developer's environment will be closer to the real environment on the production server.
At the same time, there is a problem: how to test the Open API on local developers' machines, if access to it is configured only for production? In this article, I want to talk about how to set up a local environment to work with the Open API in a standard development cycle. I’ll make a reservation that I’ll consider Windows development using Microsoft technologies, but the idea can be easily transferred to other platforms.
So, the essence of the problem. As stated in the documentation, to configure, you need to create a VKontakte application. It is important to specify the address of your site and the base domain:
When initializing the Open API on your VKontakte site, it will match the application identifier specified in the apiId parameter and the URL of the site on which this initialization is performed. If the URL does not match the parameters entered in the settings of your application (see above), then we will receive an error message: “Open API security breach”. This is a problem because, for example, when developing using Visual Studio, sites are often tested locally using the embedded web server at http: // localhost: port (where port is a number, port number). But at the same time, the Open API stops working for the reasons stated above - on local machines of Vkontakte, it’s not the resolved site address ( http://example.com ), but the local site http: // localhost: port . How to solve this problem?
')
The essence of the solution is quite simple: you need to configure the local environment so that requests to the site address specified in the VKontakte application settings ( http://example.com ) are not forwarded to the Internet-accessible production server via DNS, but to the local site on the machine developer. In this case, the developer will be able to test the Open API, because now his local site will have the address http://example.com allowed from the point of view of VK.
Setup consists of several steps. First of all, you need to edit the windows \ system32 \ drivers \ etc \ hosts file. You need to insert the following entry:
127.0.0.1 example.comSo all requests to example.com will be redirected to the local machine. Now you need to configure a local web server (in our case, IIS 7) to redirect requests to example.com to a local copy of the developer's site. To do this, create a new web site in IIS Manager, configure the physical path to the folder with the site files and specify the following bindings:
And finally, the last step in the event that a proxy is used on the local machine. In the browser settings (in IE, it is Tools> Internet Options> Connections> LAN Settings> Advanced) you need to add example.com to the list of exceptions (Do not use proxy server for meetings beginning).
Several limitations of the described approach: first, developers will not be able to go to the production site from their machines and to the local site at the same time. In order to install on production they will need to change their hosts file (remove the above entry). And secondly, they will be forced to use IIS as a web server during development, abandoning Visual Studio’s embedded web server. But as practice shows, the last limitation is rather a plus, since developer's environment will be closer to the real environment on the production server.
Source: https://habr.com/ru/post/94834/
All Articles