[BUG] v3.2.0 Origin field in log not populated
The origin field in the logs does not seem to be populated anymore for me in v3.2.0. I know I submitted https://github.com/tobychui/zoraxy/pull/593/files but I don't think that would have broken it?
I guess r.URL.Hostname() isn't being populated for some reason?
2025/04/01 14:39:41 [2025-04-01 14:39:41.615484] [router:host-http] [origin:] [client: 192.168.10.1] [useragent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0] GET /fonts/bwi-font.8c9145c8081830bc5ee5.ttf 200
2025/04/01 14:39:41 [2025-04-01 14:39:41.689937] [router:host-http] [origin:] [client: 192.168.10.1] [useragent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0] GET /images/favicon-32x32.png 200
2025/04/01 14:39:41 [2025-04-01 14:39:41.692010] [router:host-http] [origin:] [client: 192.168.10.1] [useragent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0] GET /fonts/dm-sans.a171ef528106917b9f81.woff2 200
2025/04/01 14:39:41 [2025-04-01 14:39:41.721521] [router:host-http] [origin:] [client: 192.168.10.1] [useragent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0] GET /cca56971e438d22818d6.json 200
2025/04/01 14:39:41 [2025-04-01 14:39:41.752463] [router:host-http] [origin:] [client: 192.168.10.1] [useragent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0] GET /api/config 200
2025/04/01 14:40:58 [2025-04-01 14:40:58.756033] [router:whitelist] [origin:] [client: 26.249.39.103] [useragent: Mozilla/5.0 (Linux; Android 7.0; SM-G930V Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36] GET / 403
2025/04/01 14:40:58 [2025-04-01 14:40:58.933486] [router:whitelist] [origin:] [client: 26.249.39.102] [useragent: Mozilla/5.0 (Linux; Android 7.0; SM-G930V Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36] GET / 403
2025/04/01 14:40:58 [2025-04-01 14:40:58.939269] [router:whitelist] [origin:] [client: 26.249.39.102] [useragent: Mozilla/5.0 (Linux; Android 7.0; SM-G930V Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36] GET / 403
2025/04/01 14:41:13 [2025-04-01 14:41:13.218297] [router:host-http] [origin:] [client: 34.180.194.113] [useragent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Mobile Safari/537.36] GET / 200
2025/04/01 14:41:49 [2025-04-01 14:41:49.033513] [router:host-http] [origin:] [client: 34.132.236.34] [useragent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Mobile Safari/537.36] GET / 200
@Raithmir No worry, that is why 3.2.0 is a pre-release. I will take a look into this issue this weekend.
@Raithmir ok that was a quick fix.
I notice the original implementation of logging actually relies on a sub-optimal implementation of dpcore (the core module of dynamic proxy that handles the packet forwarding). The original implementation modify the incoming request (including the hostname and other information) and send it out to the upstream. However, when the dpcore function ProxyHTTP exit, it didn't clean up the request and relies on GC to clean up the content of the request. That is what makes the logger (which done its logging after the request has been proxied) be able to get host information from the now "consumed" request object.
The commit I just pushed should fixed this. Now you get downstreamHostname string, upstreamHostname string to work with in the logging function.
Btw, if you want to become the Crowdsec compatibility maintainer for Zoraxy, feel free to let me know :D
Excellent, I'll try and rest in the next couple of days. More than happy to keep the Crowdsec parser updated. I'd submitted a pull request there but it's waiting on approval.
The v3.2.1 has been released with the fix for this issue.