[
https://issues.apache.org/jira/browse/FINERACT-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18061003#comment-18061003
]
saifulhuq commented on FINERACT-2485:
-------------------------------------
Hi [~aleks],
Apologies for the delay. I've spent the last few days mapping out the
system-wide generic approach aligned with FINERACT-2169. Instead of patching
individual modules, I am proposing a centralized Idempotency Interceptor at the
Spring web layer.
Here is the revised architectural blueprit for the POC:
1. Centralized Interceptor (Spring {{{}OncePerRequestFilter{}}}) We intercept
all incoming mutating requests (POST, PUT, PATCH) at the API gateway level
before they hit the domain controllers. The interceptor will look for a
standard {{Idempotency-Key}} HTTP header.
2. Storage & Concurrency Handling We need a fast, atomic data store to track
these keys. I propose a dedicated database table (e.g.,
{{{}m_idempotency_store{}}}) with a unique constraint on the
{{(idempotency_key, client_id)}} composite index.
To prevent race conditions on concurrent identical requests, the interceptor
will attempt a database insert. If a {{DataIntegrityViolationException}}
(unique constraint violation) is thrown, we immediately short-circuit the
request and return a {{409 Conflict}} (or the cached response from the initial
successful run).
3. Integration with FINERACT-2169 This generic filter acts as the first line of
defense. It completely decouples the idempotency logic from the downstream
Savings and Loans modules. The core command processing engine will only receive
deduplicated, verified requests. We will control this via a global toggle
({{{}fineract.idempotency.enabled=true{}}}) to ensure zero regression for
legacy API consumers not sending the header.
I am spinning up a draft PR with the {{OncePerRequestFilter}} implementation
and the DB schema changes. Let me know if you see any immediate architectural
red flags with relying on a DB unique constraint for the atomic lock given
Fineract's current deployment patterns.
> [GSoC 2026] [POC] Standardize and Harden Transaction Idempotency for Savings
> and Loans
> --------------------------------------------------------------------------------------
>
> Key: FINERACT-2485
> URL: https://issues.apache.org/jira/browse/FINERACT-2485
> Project: Apache Fineract
> Issue Type: Task
> Reporter: saifulhuq
> Priority: Major
> Labels: gsoc2026, poc, security
>
> *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)
