Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add configurable support to respect the "X-Forwarded-For" header for listener metrics #21

Closed
BusterNeece opened this issue Feb 3, 2018 · 1 comment

Comments

@BusterNeece
Copy link

BusterNeece commented Feb 3, 2018

As the developer of a radio webcast management tool, I have been asked by multiple users to implement support for the main branch of Icecast, as opposed to the current support my application has for a custom compiled copy of Icecast-KH.

One of the largest obstacles to switching back to the main Icecast branch is the fact that there exist a number of radio licensing services that offer to proxy a radio connection through their servers, track the traffic and ensure royalties are paid accordingly. Because the traffic arriving at Icecast's doorstep appears to all be from the same IP, however, it's impossible to distinguish the actual listeners in question or their geographic areas.

Karl Heyes had adopted a somewhat novel solution to this problem: specifying a whitelist of IPs that are allowed to send the X-Forwarded-For header as part of their traffic. If the inbound listener has this header and is being proxied from a whitelisted IP, the internally referenced IP is updated to the forwarded address instead, allowing for proper metrics and tracking. Unfortunately, a limitation of this approach is that every IP that will send the header must be known ahead of time, which is impossible if IPs are dynamically assigned (a-la Docker containers) from a broad pool.

If this feature or some facsimile of it were implemented on the main Icecast branch (alongside the SSL improvements that enable LetsEncrypt, see ticket #20) it would far and away be the key to ensuring that several radio services feel comfortable making the switch back to the main branch.

I'm not sure that this Github Issues section is heavily used by the Icecast dev team, but hopefully the feedback gets into the right hands. Thank you for your time!

Edit: It appears I was blocked from Xiph's GitLab entirely, and my account deleted, for having submitted this request. I don't understand the rationale behind that decision at all, as I have been quite civil and appreciative of the work done by Icecast maintainers. I am a FOSS maintainer myself and the work I produce is entirely free to the public and non-commercial in nature, licensed under the AGPL. This decision confuses and upsets me greatly.

@dm8tbr
Copy link
Contributor

dm8tbr commented Feb 4, 2018

We're tracking this already as https://trac.xiph.org/ticket/1959 (now locked)
That ticket is now moved to: https://gitlab.xiph.org/xiph/icecast-server/issues/1959
We fully expect this to be in the upcoming 2.5 release.

Please understand that to avoid duplication I'll be closing this ticket to avoid duplication.

@dm8tbr dm8tbr closed this as completed Feb 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants