Ok. Understood but… We would need a mentor who is expert enough in this to be involved.
Also, a key principle is to keep backwards compatibility for existing users of current api idempotency. This makes it non trivial. I believe that also we want to make it clear that these are POCs per the write ups Sent from Gmail Mobile On Mon, Feb 9, 2026 at 1:59 PM Mohammed Saifulhuq < [email protected]> wrote: > Hi James and Community, > > Responding to the call for additional GSoC ideas: > > I would like to propose a project focused on **Transaction Security & > Idempotency Hardening** (aligning with the 2026 Security theme). > > **Context:** > While working on the 'Force Withdrawal' Core Engine (PR #5465 > <https://github.com/apache/fineract/pull/5465>), I observed that while > Fineract has an existing mechanism for command tracking > (`m_portfolio_command_source`), its enforcement is inconsistent across > different APIs. This leaves specific transaction paths vulnerable to > "Replay Attacks" (double-charging) during network timeouts. > > **Proposed Scope (Manageable & Targeted):** > 1. **Audit:** Map the current state of Idempotency enforcement across > Savings and Loan transaction APIs. > 2. **Standardize:** Refactor the existing `IdempotencyKey` pattern to > ensure it is strictly enforced for all critical financial transactions > (starting with Savings). > 3. **Harden:** Add Integration Tests to simulate network replays and > verify that the system correctly rejects duplicate requests. > > I believe this fits the "Small, Manageable, High-Impact" criteria.. > > If this aligns with the roadmap, I would be happy to create a JIRA ticket > (e.g., FINERACT-24XX) and draft the detailed proposal. > > Best regards, > Mohammed Saifulhuq > (Contributor, PR #5465 <https://github.com/apache/fineract/pull/5465>) >
