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
