SDK Fetch Operations

The Approov SDK supports a number of different types of "fetch" operation. These are fetchApproovToken, fetchApproovTokenAndWait, fetchSecureString, fetchSecureStringAndWait, fetchCustomJWT or fetchCustomJWTAndWait. This supports the fetching of Approov tokens, secure strings and custom JWTs with variants for synchronous (blocking) and asynchronous (non-blocking) calls.

All fetches return a standard Fetch Result, either as the return result or as a parameter to a callback function. This provides the results of the fetch operation.

Fetch Status Handling

Every fetch provides an Approov Fetch Status, providing information about the reason for any fetch failure to determine how the app should react. This status can be obtained as follows, assuming approovResult is the instance of the Fetch Result obtained.

Java

String status = approovResult.getStatus();

Swift

let status = approovResult.status

The possible status results are enumerated in the table below along with the recommended action and a description of the associated meaning. Note that all iOS errors are prefixed by ApproovTokenFetchStatus..

Status (Android / iOS)	Recommendation
SUCCESS / success	Continue
UNPROTECTED_URL / unprotectedURL	Continue
UNKNOWN_URL / unknownURL	Continue
NO_APPROOV_SERVICE / noApproovService	Continue / Retry
NO_NETWORK / noNetwork	Retry
POOR_NETWORK / poorNetwork	Retry
MITM_DETECTED / mitmDetected	Retry
REJECTED / rejected	Message
BAD_URL / badURL	Error
DISABLED / disabled	Error
UNKNOWN_KEY / unknownKey	Error
NA / badKey	Error
NA / badPayload	Error
NO_NETWORK_PERMISSION / NA	Error
MISSING_LIB_DEPENDENCY / NA	Error
INTERNAL_ERROR / internalError	Error
NA / notInitialized	Error

The Recommendation column shows how the app logic should proceed if it receives the given error state. There are four possible options:

• Continue: Indicates that the app should go ahead and make the API call as expected.
• Retry: Indicates that the app should not attempt the API call. This is because it has not been possible to complete the fetch due to some network conditions. The Approov SDK already makes various retries, so there is probably no point in performing a further automated retry. Instead, the retry should require a further user initiated event. The typical case will be when the device has no (or very poor) network connectivity, so some user initiated event is required to retry when connectivity has been restored. Note that a special message might be appropriate if MITM is detected on the Approov channel, as the network being used might be inappropriate as it intercepts TLS. The user will need to connect to a different network to use the app.
• Message: Indicates that a message needs to be presented to the user about why it is not possible to proceed.
• Error: This indicates an error condition that should not occur in a production app. We recommend that this condition is logged with any crash reporting SDK that you may be using. The next step will depend on your general strategy for error handling. You could go ahead and make the API call, but use the loggable token as any Approov token. This will of course be rejected by the backend, but will provide loggable information there.