Planned Backwards Compatibility Changes
  • 11 Nov 2020
  • 5 Minutes To Read
  • Print
  • Share
  • Dark
    Light

Planned Backwards Compatibility Changes

  • Print
  • Share
  • Dark
    Light

Overview

Change Reference ID Backwards compatible until
Change for Users with restricted branch access via API 2.0 across Mambu CORE-1843 24th September 2020
Replacing Default Sort Criterion 'lastModifiedDate' with 'creationDate' for Paginated Lists via API 2.0 across Mambu DEP-1580; CORE-2721; CUS-2438; CUS-2445 30th September 2020
Apply Read permission standards on API 1.0 GET 'Branches' endpoints ADM-2011 12th November 2020
Apply Read permission standards on API 1.0 GET 'Centres' endpoints ADM-2083 12th November 2020
Update on the data access model for GET/POST:search APIs NTF-133 5th February 2021
Upgrade to latest AWS 'Application Load Balancer' (ALB) security policy requiring 'forward secrecy' and 'strong protocols and ciphers' IAM-356 Postponed to 2021 - We will follow-up with a new email announcement as soon as we re-sechdule this upgrade.

Change for Users with restricted branch access

Mambu has made a change to the API GET request: /api/loans/ when an ‘accountState’ filter is used (for example; /api/loans?accountState=PENDING_APPROVAL or /api/loans?accountState=ACTIVE). This API call is used to retrieve all loan accounts with the given state and currently returns accounts at all branches even for users who have restricted branch access.

Currently, when running a GET API call for any state of the loan account, we do not perform any branch validations. As an effect, regardless of a user's branch access, the GET API call for loan accounts of any state would return all matching accounts for all branches.

In order to correct this behaviour, we have introduced filtering of the results, according to the branches to which the user has access. Running a GET API call will now return loan accounts from only those branches that the user has access to.

Replacing Default Sort Criterion 'lastModifiedDate' with 'creationDate' for Paginated Lists via API 2.0 across Mambu

When retrieving paginated lists of clients, deposit or loan accounts via API 2.0, Mambu might return the pages with missing and duplicate entries. By default the retrieved lists are currently sorted by “lastModifiedDate”, which is a mutable field. Between two API calls (to retrieve different pages of the same list), some accounts or clients could be modified and therefore they would change order in the retrieved pages. In certain integrations relying solely on an entity's position in the list, this could lead to missing entries and duplicates.

To create predictable and consistent lists, we are redesigning our API 2.0 GET endpoints to sort retrieved lists across Mambu by “creationDate” — an immutable field. This change affects the following endpoints:

  • GET /api/deposits (DEP-1580)
  • GET /api/loans (CORE-2721)
  • GET /api/clients (CUS-2438)
  • GET /api/groups (CUS-2445)

Apply Read permission standards on API 1.0 GET 'Branches' endpoint

With the introduction of Granular Administrator Permissions Standards and granular permissions for Branches with Mambu V9.54, you can now access and use 'Branches' via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behaviour on top, we would like to let you know that we will be requesting View permission in order to access the following endpoints starting with the week on November 12th 2020.

  • GET /api/branches
  • GET /api/branches/{branchID}

This gives you 3 months to prepare the transition to this new behaviour and ensure none of your integration relies on access without standard permission authorisation to these endpoints.

Apply Read permission standards on API 1.0 GET 'Centres' endpoint

With the introduction of Granular Administrator Permissions Standards and granular permissions for Centres with Mambu V9.54, you can now access and use 'Centres' via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behaviour on top, we would like to let you know that we will be requesting View permission in order to access the following endpoints starting with the week on November 12th 2020.

  • GET /api/centres
  • GET /api/centres/{centreID}

This gives you 3 months to prepare the transition to this new behaviour and ensure none of your integration relies on access without standard permission authorisation to these endpoints.

Scheduled upgrade to latest AWS 'Application Load Balancer' (ALB) security policy requiring 'forward secrecy' and 'strong protocols and ciphers'

At Mambu, we are on a mission to continuously improve our product as well as our product security.

In order to provide a secure communication channel and keep high security standards, we are announcing the intention to make scheduled update of the AWS Application Load Balancer (ALB).

Since this update cannot be done while maintaining backwards compatibility, we would like to let you know that we intend to updatw the AWS Application Load Balancer for all Mambu Capabilities, in the week of November 23rd, 2020. in the first half of 2021.

What is the impact?

We will switch all our load balancer security policies to the latest version of ALB; this includes the Mambu monolith, new capabilities, MPO and MyMambu.

This update might break existing customer integration and the usage of Mambu app with outdated browsers as ELBSecurityPolicy-FS-1-2-Res-2019-08 is the most restrictive policy available till date. This policy supports TLS 1.2 only and includes only ECDHE (PFS) and SHA256 or stronger (384) ciphers.

For more details, please see Application Load Balancer and Network Load Balancer Add New Security Policies for Forward Secrecy with More Stringent Protocols and Ciphers.

More information can be found in our related email campaign, sent on August 25th, 2020 and which you can also preview here.

Update on the data access model for GET/POST:search APIs

We want to ensure that the data visibility model provided by the branch assignment for each user works consistently across all interfaces.

This impacts all READ (GET or POST:Search) operations done via API, both 1.0 and 2.0, for the following entities:

  • Clients & Groups
  • Deposits
  • Loans

To better understand the change, let’s take two examples, one of the current behavior and one of the new behaviour:

Current behavior:

Given a non-admin user with Mambu and API access rights,
And the user is assigned to Branch A
When the user retrieves all deposit accounts against all Branches
Then all deposit accounts from all branches will be returned.

New behavior:

Given a non-admin user with Mambu and API access rights,
And the user is assigned to Branch A
When the user retrieves all deposit accounts against all Branches
Then only deposit accounts for Branch A will be returned.

Please see below the associated ticket numbers for each change:

API 2.0

NTF-142 - Releases all changes related to GET/POST:Search endpoints for Clients and Groups

CORE-2775 - Releases all changes related to GET/POST:Search endpoints for Loan Accounts

DEP-1639 - Releases all changes related to GET/POST:Search endpoints for Deposit Accounts

API 1.0

NTF-142 - Releases all changes related to GET/POST:Search endpoints for Clients and Groups

CORE-2785 - Releases all changes related to GET/POST:Search endpoints for Loan Accounts

DEP-1639 - Releases all changes related to GET/POST:Search endpoints for Deposit Accounts

Was This Article Helpful?