Hey guys, I'm not up to speed on everything here. If we're talking about logging IP addresses of the user, I'd strongly advise against it.
There are many regulations on handling personal data which could make it even harder to introduce Fineract into a business. For example IP addresses are considered personal data in the context of GDPR and should be handled accordingly. If Mexico has a requirement that this should be done, I'm sure this could be a "plugin" of some kind in Fineract, or at least must be controlled with a specific environment variable instead of just the log level. Although, I'd really appreciate talking through rather the requirement in Mexico because there could be other solutions solving this exact same problem but without touching Fineract. Best, Arnold On Wed, Jul 2, 2025 at 8:47 PM VICTOR MANUEL ROMERO RODRIGUEZ < victor.rom...@fintecheando.mx> wrote: > 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 >>> >> >>
