Admin Page Doesn't Show X-Forwarded-For Data

[CodeSteele]

Kind of fallout from #195, but as part of getting the x-forwarded-for header, we can't tell where the client is coming from via the admin page, probably list one (or both, or all?) of the source information would be helpful.

[karlheyes]

are you saying that you are seeing, on the admin page for listeners, the IP address shown as the proxy and not the one in XFF when you have the x-forwarded-for tag set?. If so then I would like to see the xml and level 4 debug of a connection attempt.

karl.

[CodeSteele]

Yep, it's the IP of the proxy, if you expect this to be showing the x-forward-for header value I'll do a bit more digging to verify everything on our side, I did make an assumption it was unsupported.

[jesseorr]

Depending on how the proxy is set up, you may have to add extra XFF headers in Icecast. For example:

• If XFF is defined as the IP of the proxy
• The proxy has more than one IP
• The IP being used by the proxy service is not the primary routed IP Then the IP that may need to be in the XFF headers of the icecast.xml file is the primary IP of the proxy server.

If you have SSH access to both, try to do ip route get <ip_of_icecast> from the proxy to make sure the IPs line up.

[karlheyes]

FYI, as of kh14, you can use a wildcard for the x-forwarded-for tag, eg 127.* or you can use multiple tags.

karl