Hi Victor, Thanks for bringing this to community attention
My 2 cents, I believe it will be a good addition to the audit trail functionality that fineract has and would support a good audit system for organizations that are looking for from the countries that are allowed to do so. We could put that under a configuration as suggested by Arnold so that it is by default not available for everyone. Regards, Bharath Lead Implementation Analyst | Mifos Initiative PMC Member | Apache Fineract Mobile: +91.7019635592 http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Thu, Jul 3, 2025 at 12:52 AM Arnold Galovics <arn...@apache.org> wrote: > 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 >>>> >>> >>>
