fbpx

GetAddressByIP – Service for Device Geolocation Determination by IP Address

Introduction: today there are many available services that provide the possibility to track the current location of a digital device. Nowadays almost any operation related to the movement of an object in space can be recorded along the route and over time.

Many companies use such services to control and optimize their business processes. The benefit lies in the fact that the application is always aware of the device location and, depending on the tasks, provides the most relevant information upon request or as an offer.

Prompt route planning, adding geo-tags in the user’s content, searching for nearby sites the user is interested in, the need to change the application interface based on the information about the user’s new location. All of the above and much more makes life much easier for the user, and helps the application to be truly useful.

Project summary: our customer has its own set of devices and applications that run on these devices. At a certain moment it became necessary to determine the location of the device using the application running on it.

Our team developed our own Mule REST service called GetAdressByIP, which can use third-party services to determine the geolocation. In cases when the IP address of the device, on which the application is deployed, is not available, X-Forwarded-For header HTTP/HTTPS is used to determine its IP address.

GetAdressByIP operation algorithm is as follows:

  1. GetAdressByIP accepts a location request. To restrict access to the application by third parties, REST interface accepts api_key in the request parameters. api_key is a unique identifier used to authenticate the calling progra.
  2. After successful authorization the IP address is extracted from the HTTP(S) header of the request, and to identify the origin of the user’s IP address, the X-Forwarded-For header, for example, can be used.
  3. After that a request is created and sent to a third-party API to obtain the user’s location in accordance with the specified configuration. The configuration specifies which third-party service should be used to determine the geolocation.
  4. The received response is sent back to GetAdressByIP, where it is processed and sent to the client application from which the original request was sent.

Data between the client and the server is exchanged in JSON format. The operation diagram of the application is shown in Figure 1.

Diagram of interaction of the implemented application with client applications and an external address determination service

Figure.  Diagram of interaction of the implemented application with client applications and an external address determination service

One of the customer’s requirements was to minimize labor costs during deployment and testing. Developers should have focused as much as possible on software product development. To fulfill this requirement, the Continuous Integration, Continuous Delivery (CI/CD) process based on Jenkins was implemented. Five processes were automated using Jenkins:

  • Build. Jenkins starts the project build after every commit.
  • Publication. It extends the product version, creates a new tag in svn, and publishes the created zip archive in Sonatype Nexus repository.
  • Changes undo. If errors occur during publication, this process helps undo all changes.
  • Release. It gets the required version of GetAdressByIP service, downloads it from Nexus, and deploys it on the Mule applications server.
  • Building and deployment are started manually and do everything the processes described above do, except release creation. It is intended for the developer, who wants to test how the application works on the Mule server.

As a result, this significantly reduced the developers’ time they spent on building, testing and deploying new versions manually.

The Data Driven Testing approach was applied during the testing phase. The performed integration tests covered a wide range of cases.

Technologies:

Stack: Mule ESB, JSON, Apache Maven, Sonatype Nexus.
Infrastructure: Jenkins, Git, Anypoint Studio.
Test Automation Libraries: MUnit.
Protocols: HTTP(S), REST.

Project features:

  • Short deadlines for the project implementation.
  • The need to determine the IP address both by the HTTP(S) header and accept it as a request parameter (for example, ?addr=123.123.123.123).
  • The need to implement CI/CD.

Project results:

  • The project was successfully implemented. We created the REST interface that can work with different IP address determination service providers, and a provider change does not affect the applications that send requests to our service.
  • The concept of CI/CD was applied.

Company’s achievements during the project:

  • The main features were covered by Unit tests.
  • Many of our best practices used for Mule solutions implementation during this project served as the basis for creating article “Best Practices for Using Mule ESB“.