TrafficDefender Mobile App Integration Options

For standard website protection, TrafficDefender operates as a reverse proxy solution, enabling Netacea to examine all requests made to the webserver. This means that TrafficDefender can replace the content of the response sent to users added to the waiting room with the HTML page created by the customer. The end user’s browser will therefore display the TrafficDefender waiting room page and the TrafficDefender JavaScript code within the page ensures that the queuing experience is fully managed.

Native mobile apps do not follow this same browser/server interaction model so an alternative approach has to be taken to gain the benefits of TrafficDefender’s virtual waiting room within this technology stack.

When discussing native mobile apps within this document it is assuming that these are using a typical native front end calling a web-based API backend and that it is the API that TrafficDefender is protecting. Apps that use a hybrid approach or are based on web views may be able to be protected using standard TrafficDefender functionality.

There are two elements to any integration with TrafficDefender.

1: Access Control

Determining whether the user should be allowed access to the site under protection or be added to the virtual waiting room.

2: Waiting Room Status

The ability to communicate to the user their current status within the waiting room, such as their queue position, queue length, time to entry etc.

Access Control

For every new visitor, TrafficDefender will assess whether there is currently space within the site and if so allocate the visitor a time-limited access token for the site. As long as it has not expired, this token is extended every time another request is seen from that user. If there are no available positions within the site at the point of the first request, the user is positioned within the virtual waiting room and assigned a queue position. The visitor remains within the waiting room until they reach the front of the queue and therefore are assigned access to the site and an access token issued.

For native mobile apps, there are two ways that this access functionality can be implemented.

Access Control Option 1: Perimeter defence

The perimeter approach involves using TrafficDefender as a reverse proxy in front of any API calls that need protecting, the mobile app will then need to determine if the response indicates that the visitor has been added to the virtual waiting room and if so alter the functionality accordingly.

Advantages

• No need to make changes to the user journey.
• Can ensure that all necessary API calls are protected by ensuring they are processed via TrafficDefender.

Challenges

• Functionality needs to be in place for all API calls that are being protected. Depending on how the app has been developed and the amount of API calls to be protected, this can be a large development task

Access Control Option 2 : Gateway Defence

Gateway defence takes advantage of the higher levels of control that apps can have over the interactions that users make with the server. Rather than positioning TrafficDefender in front of API calls, the app makes a call to TrafficDefender before any API calls are made to determine if there is available space in the site. If so, TrafficDefender
allocates the visitor a position within the site and the app, therefore, allows this visitor to use functionality as normal. If there is no space then the visitor is put into the waiting room and the app prevents them from accessing any other functionality until they reach the front of the queue and are allowed into the site.

Because TrafficDefender is not aware of any API calls being made, it will be up to the app to make periodic “keep alive” calls to TrafficDefender as long as the visitor is active on the app to ensure that the visitor session remains active.

Advantages

• Single point of change to app workflow
• Minimises the number of requests made via TrafficDefender

Challenges

• Requires consideration of how to adapt the workflow if this is not done correctly API calls could miss protection.
• It becomes the responsibility of the app to maintain a user session within TrafficDefender

Waiting Room Status

Having identified that the user should be added into the waiting room, this must be communicated back to the user, providing them with regular updates on their position with the queue, time to entry etc.

TrafficDefender can facilitate this by either providing a full HTML page to display to the user or by providing a JSON dataset of all waiting room related data. These two alternatives form the basis of the two options described below.

Waiting Room Status Option 1: Webview

This option takes the HTML page returned by TrafficDefender and displays the HTML within a webview inside the mobile app.

The HTML page will handle the full queuing process, making regular requests to update the display until the user is granted entry to the site.

Functionality needs to be added to the webview to detect when the user is granted access to the site and revert the app to standard functionality.

Advantages

• Can use pre-designed HTML pages stored in TrafficDefender.
• Will handle all regular updates of waiting room status.

Challenges

• App will have to handle the creation and removal of webview when users enter and exit the waiting room.
• Visual appearance may not be fully integrated with the rest of the app.

Waiting Room Status Option 2: In-App Display

The alternative option is that TrafficDefender can return a JSON dataset that includes
all the data relating to the user and their position in the waiting room. This data can
then be used to modify app behaviour to inform the user of their current status.

In this approach, it becomes the responsibility of the app to make regular requests to
TrafficDefender to get the updated status for the user or to be informed when the user
has been granted access to the site.

Advantages

• Can be designed to be fully visually integrated with look and feel of the app.

Challenges

• The app is responsible for tracking updates to waiting room status.