Once you've started using Approov, we find it unlikely that you will want to cancel. However, it is a legitimate concern for potential users and, as we have a quick and simple cancellation process, I am happy to address it here. First up, consider the following scenario at the point of cancellation:
- Your server-side expects an Approov token on every request
- You have the Approov SDK integrated with one or more versions of a deployed app
The first point is easy to address; change your server implementation to ignore all tokens. However, the second would be more complicated had we not taken care as we developed the solution. The subtlety comes from the behavior of the Approov SDK as it attempts to get a token, see my last post for an overview of the Approov cloud service architecture:
- Attempt to retrieve a token from the primary Approov service.
- On failure, attempt to retrieve a token from the failover Approov service.
- On failure, return an empty token with the expectation that the app will retry after a short period of time.
So, if we play out the scenario with a naive cancellation policy; one where Approov end-points used by the app simply disappear, then we get the following sequence (I want to stress that this is not what happens):
- Primary attempt fails (after a timeout in the worst case scenario)
- Failover attempt fails (after a timeout in the worst case scenario)
- App receives no token and retries after a timeout.
Although the precise behaviour of your app in this situation would be down to you, it is clear that behavior like this would probably cause the performance of your app to degrade significantly, perhaps making it unusable. Also, Approov integration would be more challenging if you had to plan for behavior like this.
Fortunately, cancellation doesn’t work like this. Instead, when you sign up to Approov you get a unique account identifier and this is used to create a couple of unique DNS records for your account; one for Approov Primary and one for the Failover. On cancellation we re-target your DNS records to point to statically served nonces and tokens - this way, as long as there is network connectivity, the SDK will receive valid values from the end-points that it hits. Your deployed apps will continue receiving all the data they need to function normally and they will therefore keep working as intended. Between us, we can work out a reasonable length of time to keep the old end-points up and running, with your users successfully using the apps with the Approov SDK for the duration.
In summary, we have taken great care while designing and constructing Approov and we want you to get the best experience and the best service while you engage with us even in the unlikely event that you want to leave.
Want to Know More?
This series of posts focuses on aspects of Approov that are sometimes misunderstood. If you have any issues you want qualified then why not ask me a question from the contact us page. Otherwise, here are some links that you may find interesting:
