Repository navigation
Conversation
DeleteAccountCascade now removes the MapperAccountHolders rows of the deleted bank_id/account_id, and DeleteBankCascade removes them for every account of the bank through it. A holder row that outlived its account was read back by AuthUser.refreshUser (for example when the former holder created another account) and the five system views were granted on the deleted account again.
…s bound to it
DELETE /obp/v4.0.0/management/cascading/banks/{BANK_ID}/accounts/{ACCOUNT_ID}
now also removes the SCA challenges of every consent whose JWT views name the
account. The consents are read from the users who hold or can see the account,
before their account access rows are deleted. The bank cascade deletes each
account through the same code.
…llenge table The account cascade looked for consents through the users who hold or can see the account, which misses a Berlin Group consent whose first challenge is still unanswered: no PSU is bound to it yet. The consents are now read from the challenges that carry a consent id and kept when their JWT names the account. The test now uses such a Berlin Group consent instead of an authorised UK consent, whose challenge is deleted once answered.
A consent's OBP_CONSENT_CHALLENGE rows are deleted when the PSU answers one correctly on POST .../consents/CONSENT_ID/authorise (the answered challenge and any other one started on the consent), and when the consent becomes REVOKED, REJECTED or EXPIRED through updateConsentStatus, revoke or the UK expiry sweep. A wrong answer keeps its row so the attempt counter still applies. Berlin Group consent challenges and transaction request challenges are left as they are, since they are read after answering.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The account cascade (
DELETE /obp/v4.0.0/management/cascading/banks/{BANK_ID}/accounts/{ACCOUNT_ID}, also used for each account by the bank cascade) now deletes the account holder rows (MapperAccountHolders) of the deleted bank_id/account_id, so a later refresh of the former holder's accounts (AuthUser.refreshUser) no longer grants system views on the deleted account. Holders of an account with the same ACCOUNT_ID at another bank are kept. The cascade also deletes the SCA challenges of every consent whose JWT views name the account; the consents are found through the challenge table, so a Berlin Group consent whose PSU has started but not answered its authorisation is covered, and the consents themselves are kept. Separately, a consent'sOBP_CONSENT_CHALLENGErows are deleted once none of them can be used any more: after the PSU answers one correctly onPOST /obp/v5.1.0/banks/BANK_ID/consents/CONSENT_ID/authorise(the answered challenge and any other started on that consent), and when the consent becomesREVOKED,REJECTEDorEXPIREDthroughupdateConsentStatus(includingPUT /management/banks/BANK_ID/consents/CONSENT_ID),revokeor the UK expiry sweep inConsentScheduler. A wrong answer keeps its row, so the attempt counter still applies, and Berlin Group consent challenges and transaction request challenges are not touched by that rule, since they are read after answering. The removal goes through a newChallengeProvider.deleteChallengesByConsentId(consentId, challengeType), and a failed delete is logged without failing the request.DeleteAccountCascadeTestandDeleteBankCascadeTestcover the holder removal, the other-bank holder being kept, and that neither reading the deleted account nor creating another account brings its access back;DeleteAccountCascadeConsentChallengeTestchecks that only the challenge of the consent bound to the deleted account goes;UKOpenBankingV401AccountInfoTestscovers a correct answer, a wrong answer, a correct answer that is then refused, the REJECTED / REVOKED / EXPIRED transitions next to AUTHORISED, and the UK expiry sweep. This combines #2959, #2960 and #2961 into one change. Not covered yet: holder rows left behind by accounts deleted before this change.