Handling verify request on end user client

Technologies used for the demonstration of end-user client implementation: Flutter, Kotlin, Dart.

In order to successfully use the Silent Mobile Verification, the end-user client should be able to:

1. Switch the device to cellular network
2. Initiate the request and follow redirects
3. Polling the result

For context, the enterprise backend service should have two endpoints exposed to the end-user client:

• /verify endpoint that starts the verify process
• /verify/result/{token} endpoint for fetching the verification result

Switch the device to a cellular network

For the verification process to work, it is required for the end-user client to make the requests over a cellular network. Note that the initial verify request toward the enterprise backend needs to be made over a cellular network only if the verify request is being made for Brazil (+55), Germany (+49), or the United Kingdom (+44) numbers. For the purpose of the demonstration, we're assuming that we need to handle these cases.

The logic of switching the device to a cellular network is done on the platform level, meaning that for Android it is done in Kotlin native, and for iOS in Swift. Since this demo's end-user client is written in Flutter, it uses Flutter's Method Channel in order to communicate between different environments.

Android implementation

Switching the device to a cellular network on Android is done by utilizing the Connectivity Manager in the following way:

1. Get ConnectivityManager service from the provided context.
2. Define a NetworkCallback object that will be used to handle the results of the network request. On success, it should use ConnectivityManager bindProcessToNetwork method to set the requested network as the default network of the client, meaning that all following connections will be made over this network.
3. Build a NetworkRequest with TRANSPORT_CELLULAR transport type (the device should use a cellular network) and NET_CAPABILITY_INTERNET (the network should be able to access the internet).
4. Request a network matching the specifications in NetworkRequest and result handling specified by NetworkCallback over the ConnectivityManager requestNetwork method.

The described process can be found here.

In order to stop forcing the cellular network and make the client use the system's default network pass null to the ConnectivityManager bindProcessToNetwork method as it is done here.

Initiate the request and follow redirects

Once the device is on a cellular network, the client is ready to initiate the verify request and follow the redirects to the network operator and Infobip.

The initial request (/verify endpoint) is a simple HTTP request containing the MSISDN that should be verified. It should return a HTTP response with the body JSON object containing the request token (the request token is required to start polling the result, see Polling the result) and optionally the redirect URL.

If the redirect URL was provided, make a GET request to that URL. On URL redirection, most of the HTTP client libraries should automatically fill the required headers and follow the redirects (see API flow diagram) out of the box, but in this demonstration it is shown how to do it manually. It can be found here. In pseudo code, this reads - if the given response HTTP status is one of the redirect codes, make a request to the URL stored in the given response's location header, making it accept json content, and filling the cookie header with the cookie header values from the given response; repeat everything with the new response until the response is not a redirect.

If the returnUrl was specified in the initial verify request from enterprise backend, the final redirect will be toward the returnUrl URL. If not, the final redirect will go toward Infobip, responding with a JSON body structure defined as:

Key	Type	Required	Description
token	string	Yes	Unique request identifier.
error	Error object	No	Information about error occurred. If there is no error this object is omitted.

Error object JSON body structure defined as:

Key	Type	Required	Description
id	integer	Yes	Identifier of the error code (see the official documentation of Infobip error codes).
name	string	Yes	Error code name (see the official documentation of Infobip error codes).
description	string	Yes	Information about occurred error.

The described process can be found here.

Polling the result

After the verify request and the redirects are completed, the end-user client is ready to start polling the result. Note that the following request does not need to be made over a cellular network.

Here, the end-user client simply checks whether the result has arrived to the enterprise backend by sending a request to /verify/result/{token} every AppConfiguration.pollingRetryIntervalSeconds seconds. The described process can be found here. In pseudocode, this reads - for AppConfiguration.pollingRetryLimit times, with AppConfiguration.pollingRetryIntervalSeconds seconds delay between requests, fetch a result from /verify/result/{token} endpoint; if the result is successfully fetched (that's indicated with a HTTP status 200 OK) at any time, return the result.