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