Skip to content

Upgrade Guide

Jump to bottom
Will Morgan edited this page Sep 24, 2020 · 26 revisions

This guide lists practical steps to ensure your app can smoothly upgrade from release to release, accounting for any breaking or incremental changes.

Upgrading from v2.2.x to v3.0.x

Assets and CDN

Apart from fonts, usage of the CDN is no longer necessary to load our dependencies. Fonts are still loaded through the CDN for the best browser performance and to avoid blocking downloads. This method also avoids penalising integrations that override any fonts in our default interface.

Customisation

  • Rename the "aborted" slot and event handlers to "cancelled".
  • Optionally implement a slot and event handler for "interrupted".

Internationalisation

Ensure that any language customisation needed for iProov Liveness is applied to the new Liveness strings: - progress_assessing_liveness - prompt_liveness_align_face - prompt_liveness_no_face - prompt_liveness_scan_completed

Native Bridge

If you haven't already, ensure that you have migrated from the legacy Native Bridge implementation described in the v2.0 -> v2.1 section.

Upgrading from v2.1.x to v2.2.x

Slots integration

Ensure that .iproov-lang-heading and .iproov-lang-term classes are added, as the deprecated behaviour of searching for h3 and div tags has been removed in this release line.

Upgrading from v2.0.x to v2.1.x

Native Bridge

To upgrade to the new Native Bridge functionality:

  1. Upgrade to @iproov/web@^2.1.
  2. Remove the prefer_app setting.
  3. If in use, rename prefer_app_options to native_sdk_options.

To support webview based apps that don't yet contain the Native Bridge 2.0 compatible iOS and Android SDKs ("legacy webview apps"):

When the integrator detects a legacy webview app, when instantiating iProov Web:

  1. Set the legacy_native_bridge option to true.
  • This would look something like: if (isLegacyWebViewApp) { element.setAttribute("legacy_native_bridge", "true"); }
  • If this is not set, then in the case of old SDKs, the unsupported event would fire rather than fail silently. This is the current scenario in Web SDK 2.0.x.
  • Note that enabling legacy mode means the SDK must be present, so it cannot be set for all user sessions (eg: desktop.)
  1. If using the standalone support checker, it must be instantiated with the legacyNativeBridge option: new IProovSupport(logger, { legacyNativeBridge: true });
  • The logger option can be null to fall back to console. Otherwise, any logger implementing the standard NodeJS or browser console logger levels will suffice.

Note that the above steps must only be taken when the integrator detects an old webview app.

To effectively support legacy cases, control is handed to the integrator to enable as they see fit. Legacy Native Bridge doesn't have any fine-grained mechanism to check whether a native SDK is available or not, and experience with customers implementing the Web SDK has shown that the integrator themselves have far better knowledge of when legacy mode would need to be invoked than the Web SDK could determine.

As Native Bridge legacy mode overrides the default Web functionality and forces traffic to the Native SDK, this means that legacy mode must only be switched on by the integrator on a per-user basis where they are able to detect the requirement for native (i.e. iOS in a Webview), while versions of their app are in the wild that still have the Native Bridge 1.0 capability.

The presence of a detected Native Bridge 2.0 installation takes precedence over legacy mode. So a given webview app could upgrade their iProov Native SDK with no immediately required action from the iProov Web integrator. In other words, until legacy mode is removed, this is a "set and forget" solution.

Clone this wiki locally