Skip to main content
Version: 2.6.x.x RR

Dynamic Backend Base URL

The Nevis Access App can handle multiple backend instances sharing the same configuration by locking in the first used backend domain for future app operations.

Use Cases

This feature is useful for several scenarios:

  • Providing internal app testers an easy way to test the Access App with several backends sharing the same configuration, for example, production, integration and testing backends.
  • Allowing the Apple App store verification, requiring manual testing by Apple, to test against a backend system not containing production data and accounts.
  • Offering a single Access App for end-users which can work with more than one backend, for example, trial and production instances.
Different backends with same access app

For this purpose, the Access App configuration holds a whitelist of backend URL domains, with which the application is allowed to communicate. For the detailed configuration information, see the Domain White List chapter in Ordering an Access App.

During the initial registration flow, the Access App analyzes the domain of the performed Out-Of-Band registration operation. If it matches one of the allowed configured domains from the whitelist, the Application locks the first matching domain. This means that this locked domain is used afterwards for all future operations.

Locking state
  • The locking state remains even after an end-user removes the last registered account from the Access App.
  • This locking state can be cleared (for example, "unlocked") by:
    1. Reinstalling the Access App.
    2. Resetting all data and settings in the Hidden Advanced Settings Menu.

Example​

  1. The MyInsurance Access App is configured and shipped for three backend instances:
    • production.myinsurance.com
    • integration.myinsurance.com
    • testing.myinsurance.com
  2. After installation, the end-user Bob performs a registration by scanning a QR code from integration.myinsurance.com.
  3. For any following operationa, the MyInsurance Access App is now locked to integration.myinsurance.com, and that backend is used for all future operations.
  4. After the backend URL is locked, any operation executed on production.myinsurance.com or testing.myinsurance.com is rejected by the application with an error.
Limitations

This feature has several limitations:

  • The dynamic backend must share the same "base configuration" of HTTP API endpoint paths.
  • In case push messages are used, the backend systems has to share the same Firebase project.

The main difference between the various configured backends is the domain the backends are served under.

Last updated on