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