You should always send an explicit abort in case a process is canceled. For example, if the user declines the confirmation of attributes during the authentication processes, the server is not aware of the client side cancellation of the process and therefore waits for an answer. To reduce the amount of unnecessary open connections and to promote a smoother flow of processes you should notify the server explicitly. The server then can for example automatically refresh the authentication QR Code displayed to the user in case the decision is reconsidered.
To abort a process, the according function abort of the XignCommon component can be used. It accepts all objects
that conform to the protocol/interface XignSessionHolder. Throughout the SDK a lot of objects hold a session and can
therefore be used to cancel the current process.
The example below shows how the process of confirming the user attributes can be aborted:
internal func cancelConfirmingAttributes(
request: AuthenticateRequest
) {
// Retrieve the XignCommon component that handles aborts.
let common: XignCommon = XignSdk.shared.xignCommon
// Retrieve the session from the current process's step.
let session: XignSession = request.xignSession
do {
try common.abortSynchronous(session)
} catch let xignError as XignSdkError {
switch AbortErrorCodes.from(xignError.errorCode) {
case .connectionError,
.keyRemovedBySystem,
.unexpectedError:
YourImplementation.handleTheError()
}
} catch {
// Other errors should not be raised normally.
// Nevertheless, to be safe, general errors should be caught and handled like
// the `unexpectedError` case.
}
}
internal fun cancelConfirmingAttributes(
request: AuthenticateRequest
) {
// Retrieve the XignCommon component that handles aborts.
val common: XignCommon = XignSdk.shared.xignCommon
// Retrieve the session from the current process's step.
val session: XignSession = request.xignSession
try {
common.abortSynchronous(session)
} catch (xignSdkException: XignSdkException) {
when (AbortErrorCodes.from(xignSdkException.errorCode)) {
AbortErrorCodes.CONNECTION_ERROR,
AbortErrorCodes.KEY_REMOVED_BY_SYSTEM,
AbortErrorCodes.UNEXPECTED_ERROR,
AbortErrorCodes.DEVICE_LOCKED -> {
YourImplementation.handleTheException()
}
}
} catch (t: Throwable) {
// Other errors should not be raised normally.
// Nevertheless, to be safe, general errors should be caught and handled like
// the `unexpectedError` case.
}
}
Note: In case of an error received from a flow function, e.g. on the
onStartAddAuthenticatorError, you do not have to call the abort function yourself, because the process is already cancelled internally.