[jira] [Commented] (FINERACT-2485) New command processing - standardize and harden idempotency

["Chia Chien Liu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FINERACT-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123634#comment-18123634 ] 

Chia Chien Liu commented on FINERACT-2485:
------------------------------------------

Thanks for working on this. While testing idempotency against current develop (4684c66, PostgreSQL) I found several behaviours that the design does not define yet; they could become acceptance tests. Method: the same Idempotency-Key header on POST /savingsaccounts/\{id}/transactions?command=deposit, for example: curl -u mifos:password -H "Fineract-Platform-TenantId: default" -H "Content-Type: application/json" -H "Idempotency-Key: K1" -d '\{"transactionDate":"05 October 2026","transactionAmount":1,"paymentTypeId":4,"dateFormat":"dd MMMM yyyy","locale":"en"}' "http://localhost:8443/fineract-provider/api/v1/savingsaccounts/2/transactions?command=deposit"

 

1. Same key, different amount (1, then 2): HTTP 200, only the first deposit is posted, and the response is the first one.

2. Same key on a different account (account 2, then account 3): HTTP 200 for account 3, but its balance is unchanged and the response contains account 2's savingsId and clientId.

3. Failed request (400), then a corrected retry with the same key: HTTP 400 again with an empty body, nothing posted.

4. A 1000-character key returns 403 (400 would be expected; possibly related to #6566).

 

Cause: CommandSourceService.findCommandSource matches on (actionName, entityName, idempotencyKey) only, so neither the target resource nor the payload is part of the request identity. The design in this ticket uses (idempotency_key, tenant_id); I would like to suggest defining what happens for cases 1 and 2 explicitly, for example: include the HTTP method and resource path in the identity, and answer 409 or 422 when the same key arrives with a different resource or a different payload fingerprint (a canonical-JSON or key-field hash avoids the attribute-ordering problem mentioned earlier in this ticket). Failed requests could replay the stored error body.

 

I saw Aleksandar's note about possibly owing a test for idempotency. I am happy to contribute a parameterized integration test covering these cases, including parallel requests with one key and a key reused across accounts, if that helps. Please tell me where you would like it so I do not conflict with the ongoing work.

> New command processing - standardize and harden idempotency
> -----------------------------------------------------------
>
>                 Key: FINERACT-2485
>                 URL: https://issues.apache.org/jira/browse/FINERACT-2485
>             Project: Apache Fineract
>          Issue Type: Sub-task
>            Reporter: saifulhuq
>            Assignee: Aleksandar Vidakovic
>            Priority: Major
>              Labels: poc, security
>             Fix For: 1.16.0
>
>         Attachments: GSoC 2026 – FINERACT-2485 Standardize and Harden Transaction Idempotency for Savings and Loans final 1_compressed.pdf
>
>
> *Goal:* Standardize idempotency enforcement to prevent replay attacks in core financial modules. *Implementation Strategy (Addressing James Dailey's feedback):*
>  # *Opt-In Architecture:* New logic will be behind a Global Configuration flag. Default remains legacy behavior to ensure 100% backward compatibility.
>  # *Phased Approach:* Audit existing {{m_portfolio_command_source}} usage and bridge gaps in the Savings module first.
>  # *Testing:* Implementation of integration tests simulating network failures/retries.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)