Hello Adam,

This is the document that we have used as reference:

https://www.rfc-editor.org/rfc/rfc7239.txt
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For

Regards

Victor

El mié, 2 jul 2025 a las 10:32, Ádám Sághy (<adamsa...@gmail.com>) escribió:

> Hi Victor
>
> Thank you for sharing the business requirement that supports the ip
> tracking capabilities!
>
> I was wondering whether you could share some information about how the
> priority order of the IP header candidates was decided.
>
> Is there a specific reason for the ordering, or is it based on best
> practice or precedent?
>
> Regards,
> Adam
>
> On 2025. Jul 2., at 18:22, VICTOR MANUEL ROMERO RODRIGUEZ <
> victor.rom...@fintecheando.mx> wrote:
>
> Hello Adam,
>
> In Mexico it is required by law to have the tracking of the activities
> that have been done by the users (staff, clients) in the core banking
> during the sessions. We have implemented this for the local
> implementations. Information cannot be stored outside of the Apache
> Fineract DB because of regulation. Of course Apache Fineract is not exposed
> directly to the internet but we forward the original IP that is used by all
> the electronic channels (mobile, web, wallets and any device that uses the
> services).
>
> Regards
>
> Víctor Romero
>
> El mié, 2 jul 2025 a las 10:12, Ádám Sághy (<adamsa...@gmail.com>)
> escribió:
>
>> Hi Victor,
>>
>> Thank you for raising this topic and for sharing the AI-generated
>> description for the story.
>>
>> I have no objections to the use of AI-generated descriptions—they can be
>> quite helpful in many cases. However, I would like to offer some
>> constructive feedback on the IP tracking proposal.
>>
>> *On IP Tracking in Fineract:*
>>
>> While I understand the points raised in the story, I’m not convinced that
>> IP tracking should be a responsibility of Fineract itself. In practice,
>> Fineract is (and should be) never directly exposed to the internet.
>> Standard deployment approaches ensure that it is always behind a VPN, a
>> company proxy, or cloud load balancers.
>>
>> As a result, the actual client IP address is typically not visible to
>> Fineract. Instead, it only receives internal IP addresses or those of
>> upstream proxies, which significantly limits the usefulness of collecting
>> IP information at the application layer.
>>
>> *Code Review: (*https://github.com/apache/fineract/pull/4825)
>>
>> The following code attempts to extract the client IP address from a
>> variety of HTTP headers:
>>
>> java
>> CopyEdit
>> private static final String[] IP_HEADER_CANDIDATES = {
>>     "X-Forwarded-For", "Proxy-Client-IP", "WL-Proxy-Client-IP",
>>     "HTTP_X_FORWARDED_FOR", "HTTP_X_FORWARDED", "HTTP_X_CLUSTER_CLIENT_IP",
>>     "HTTP_CLIENT_IP", "HTTP_FORWARDED_FOR", "HTTP_FORWARDED", "HTTP_VIA", 
>> "REMOTE_ADDR"
>> };
>> public static String getClientIpAddress(HttpServletRequest request) {
>>     for (String header : IP_HEADER_CANDIDATES) {
>>         String ip = request.getHeader(header);
>>         if (ip != null && ip.length() != 0 && 
>> !"unknown".equalsIgnoreCase(ip)) {
>>             log.debug("SEND IP : {}", ip);
>>             return ip;
>>         }
>>     }
>>     log.debug("getRemoteAddr method : {}", request.getRemoteAddr());
>>     return request.getRemoteAddr();
>> }
>>
>> My concerns with this approach are as follows:
>>
>>    -
>>
>>    If a third-party client sets these headers, the value cannot be
>>    trusted and is trivial to spoof.
>>    -
>>
>>    If an internal system is responsible for propagating the correct
>>    client IP, then that system should also handle any geolocation, security
>>    filtering, or risk analysis—this is typically managed by firewalls and
>>    security appliances.
>>    -
>>
>>    Therefore, I am not sure that handling IP addresses at the Fineract
>>    application layer adds any real value or security benefit.
>>
>> *Story Requirements: (*
>> https://issues.apache.org/jira/browse/FINERACT-2314)
>>
>> Several use cases were listed for IP tracking:
>>
>>    -
>>
>>    *Security & Fraud Prevention:* Not within Fineract’s scope; there are
>>    dedicated third-party solutions for this.
>>    -
>>
>>    *Regulatory Compliance & Legal Requirements (AML, KYC, GDPR, etc.):* 
>> Again,
>>    these should be handled by specialized systems, especially if Fineract is
>>    not directly accessible.
>>    -
>>
>>    *Audit & Forensic Investigations:* I can understand the value here
>>    and would accept recording IP addresses for audit purposes, provided the
>>    limitations are clear.
>>    -
>>
>>    *Geolocation-based services & risk scoring:* Again, this is out of
>>    Fineract’s scope; better handled externally.
>>
>> *Regarding the PR:*
>>
>> I understand the PR focuses on storing the caller IP address for write
>> operations for audit and forensic purposes. While I see some value in this,
>> it should be clear that the collected IP may not always be meaningful, and
>> can easily be manipulated.
>>
>> One further question:
>> *How was the priority order of the IP header candidates decided?*
>> Is there a specific reason for the ordering, or is it based on best
>> practice or precedent?
>>
>> @Victor and fellow community members,
>>
>> I’d like to hear everyone’s perspective on this topic—particularly around
>> the inclusion of IP address tracking in Fineract and its alignment (or not)
>> with our project’s security and architectural principles.
>>
>> What are your thoughts on the value and potential risks of handling
>> client IP addresses within Fineract, versus relying on external
>> infrastructure or third-party solutions for these functions?
>>
>> Looking forward to the community’s insights.
>>
>> Best regards,
>> Adam
>>
>
>

Reply via email to