[
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)
