mirror of
https://github.com/pocket-id/pocket-id.git
synced 2025-12-09 17:23:22 +03:00
🐛 Bug Report: Audit Log doesn't show real local IP #326
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @heyitsme-milan on GitHub.
Reproduction steps
Set up nginx reverse-proxy and proxy_pass to pocket-id.
Pocket ID is set up with
TRUST_PROXY=true
CADDY_DISABLED=true
When looking at the audit log, the IP listed here is the gateway of the containers network when accessing pocket id internally. External access works fine.
In the nginx reverse-proxy, it is configured to use
nginx.conf: set_real_ip_from 10.0.0.16/28;
nginx.conf: real_ip_header X-Forwarded-For;
nginx.conf: real_ip_recursive on;
In the proxy config, I've additionally set
proxy_set_header X-Real-IP $remote_addr;
The internal subnet of my clients is 192.168.0.0/24
Expected behavior
Local and external IP addresses are shown correctly in the audit log
Actual Behavior
External IP addresses are shown correctly in audit log.
Internal IP addresses are not shown correclty in audit log.
Version and Environment
v0.35.2
Log Output
No response
@savely-krasovsky commented on GitHub:
From what I see,
TRUST_PROXYis not used when Caddy is disabled.Also I don't see any. Nevermind, Pocket ID uses Gin andX-Forwarded-FororX-Real-Ipmentions in the codebase. I think Caddy can transparently override src ipClientIP()method to get incoming IP.@savely-krasovsky commented on GitHub:
@Zyanido unfortunately both rootless Docker and Podman seem to have that problem: https://docs.docker.com/engine/security/rootless/#docker-run--p-does-not-propagate-source-ip-addresses
In my case I solved problem by switching from compose files to podman quadlets and using systemd socket activation. @eriksjolund has very good repo with examples: https://github.com/eriksjolund/podman-networking-docs
But AFAIK docker doesn't support socket activation.
From what I heard and read new
pastaengine should work, but I wan't able to setup intel-container communication, AFAIK it could not even possible at the moment. Maybe Erik will correct me, he seems to be an expert in this area.@savely-krasovsky commented on GitHub:
Yeah, I have the same problem with Traefik (I don't use any additional proxies). Traefik by default set's those: https://doc.traefik.io/traefik/getting-started/faq/#what-are-the-forwarded-headers-when-proxying-http-requests
I also set
TRUST_PROXY=true.@heyitsme-milan commented on GitHub:
@savely-krasovsky I'm using the Docker Engine 27.0.3 and it is not running in rootless mode.
To test things, I've created another nginx container to which my nginx reverse proxy will forward to.
Without additional settings, I can see
$_SERVER['HTTP_X_REAL_IP'] | 10.0.0.17
$_SERVER['HTTP_X_FORWARDED_FOR'] | 10.0.0.17
So it seems like it is more of an nginx problematic than pocket id.
Will try some tests after work. Thanks!
@savely-krasovsky commented on GitHub:
@Zyanido what containerization engine do you use? I find my PR useful (since in my tests
X-Forwarded-Foris not working without patch), but my problem was different. I experimented with rootless Podman and to my dismay they still cannot provide right source IP without complicating setup (or loosening security). So in my exact case Traefik just didn't saw correct remote IP at all.@stonith404 commented on GitHub:
I'm closing this because @Zyanido's problem seems fixed. Regarding your issue @savely-krasovsky, we can discuss this further in the PR.
@heyitsme-milan commented on GitHub:
@savely-krasovsky just dig into the issue - tl;dr it is caused by the userland proxy of docker
https://github.com/moby/moby/issues/15086
/etc/docker/daemon.json { "userland-proxy": false, "iptables": true }It is working fine now:
Do you want to keep the issue open because of your PR?
BR and many thanks!
@heyitsme-milan commented on GitHub:
@savely-krasovsky thanks for the links!
But as I am running docker with root privileges, this shouldn't be the issue in my case.
Btw, I'm running Unraid, so I'm stuck with the docker version and dockerMan
@savely-krasovsky commented on GitHub:
I think it's still an issue, since in my tests
X-Forwarded-Fornot handled without a patch at all.@savely-krasovsky commented on GitHub:
@Zyanido oh, sorry, I skipped "not" while reading 🫠