[Bug] Active Sessions / audit log show proxy IP instead of real client IP

[ehribeiro]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

utils/auth.py uses request.remote_addr directly to record session/activity
IP addresses in several places, instead of using get_client_ip()
(defined in pegaprox/utils/audit.py:217), which correctly resolves
X-Forwarded-For/X-Real-IP against the configured Trusted Proxies list.

As a result, the "Active Sessions" screen (My Profile → Active Sessions)
and the session last_ip/activity history show the reverse proxy's IP
(or the internal Docker network IP) instead of the real client IP — even
with Trusted Proxies correctly configured. Other parts of the system
(e.g. the LDAP authentication log) already use get_client_ip() correctly
and show the right IP for the very same request, confirming the
inconsistency.

Affected lines

pegaprox/utils/auth.py:

• line 543: 'ip': request.remote_addr if request else None,
• lines 592-593: current_ip = _req.remote_addr
• line 766: request.remote_addr passed directly into the activity-log insert

Working reference (for contrast)

pegaprox/api/auth.py lines 84-85, 265-266, 868-869 already import and use
_is_trusted_proxy from pegaprox.utils.audit correctly:

from pegaprox.utils.audit import _is_trusted_proxy
is_secure = request.is_secure or (_is_trusted_proxy(request.remote_addr) and request.headers.get('X-Forwarded-Proto') == 'https')

Suggested fix

Import get_client_ip from pegaprox.utils.audit in utils/auth.py
(same pattern already used for _is_trusted_proxy in api/auth.py) and
replace request.remote_addr with get_client_ip() at the three
affected call sites.

Steps to Reproduce

1. Deploy PegaProx behind a reverse proxy (tested with Nginx Proxy Manager)
2. Configure Trusted Proxies correctly (Settings → Server → Reverse Proxy)
3. Log in from an external client
4. Check Settings → LDAP auth log → shows correct external client IP
5. Check My Profile → Active Sessions → shows the proxy/Docker-network IP
   instead of the same client's real IP

Expected behavior

1. Real IP address must be visible instead of internal trusted proxies

Environment

• **PegaProx Version: 0.9.13
• **Installation Method: Docker
• **OS: Ubuntu 24.04
• **Browser: Firefox 152
• **Behind Reverse Proxy? Ngnix
• UI? Modern / Corporate

Logs

[LDAP] TLS certificate verification disabled - MITM risk
[LDAP] Failed login for LDAP user 'zati@b.eclass' from 200.xxxx.xxx.xxx
[LDAP] TLS certificate verification disabled - MITM risk
[LDAP] TLS certificate verification disabled - MITM risk

Screenshots

Checklist

• [X ] I have searched existing issues to make sure this is not a duplicate
• [ X] I am using the latest version of PegaProx

[mkellermann97]

Spot on, @ehribeiro — thanks for the precise report, exact lines and the working reference included. Confirmed and fixed on Testing (084f230): create_session, the session-IP-change check, and the API-token last_used_ip now all go through get_client_ip() — the same trusted-proxy resolver the login/LDAP paths already used — so Active Sessions and token history show the real client IP instead of the proxy/Docker address. Your report also helped catch a related trap: the optional session-IP-pinning guard had to move in lockstep, otherwise it'd compare a real IP against a stored proxy IP and false-trip, logging good users out. Verified in-process with an X-Forwarded-For behind a trusted proxy (real IP recorded; direct connections unchanged). Ships in the next release — opencollective.com/pegaprox keeps these going. — Marcus