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 (<[email protected]>) 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 >
