Hi, On Fri, 21 Nov 2014, "Thomas B. R?cker" wrote:> Unrelated to liquidsoap, if you use mountpoint credentials to update > metadata for a stream, but are on a different IP than the connected > source client, that will fail.I would like to request that this be configurable somehow. I agree that this is undesirable under most circumstances, but there are situations where this is required. One example I can think of. I was working for an organisation that needed to track metadata for royalty reporting. The playout software in use sent metadata, including album and record label, to a PHP script via a get request. This script filed it in a MySQL database, along with other details like date and time, source IP and listener count, and also passed the metadata on to the streaming server. Such a setup would not work on current Icecast. Another example was just posted to the mailing list. The idea of being able to put details in a cue file which could be used to send metadata during the repeat of a live show. Rather than needing support in the source client, an external utility could be fired off at the same time playout commences, and the metadata could be sent at the right time from potentially a different IP address. The above-mentioned database, for example, could be used for this sort of thing in addition to its original purpose. There are probably other applications. I know of at least one regular poster to this list who has not upgraded their Icecast installation because they rely on this feature. I would like to suggest a couple of possibilities. 1. The ability to turn the feature on and off. This may not be the best route but it may be the simplest to implement. 2. An option to allow metadata from the local host as well as the source address. 3. The ability to specify a whitelist of allowed IP addresses. Being able to do this on a per mount basis as well as globally would be ideal. Thoughts? Geoff.
On 11/21/2014 02:21 PM, Geoff Shang wrote:> Hi, > > On Fri, 21 Nov 2014, "Thomas B. R?cker" wrote: > >> Unrelated to liquidsoap, if you use mountpoint credentials to update >> metadata for a stream, but are on a different IP than the connected >> source client, that will fail. > > I would like to request that this be configurable somehow. I agree > that this is undesirable under most circumstances, but there are > situations where this is required.It has been requested before and the answer is still the same, we have it on our radar and it will happen in the future. If someone wants to make sure it's in the $next_release, then possible avenues are: - sending a patch (after discussing how to approach this, see below) - sponsoring development of a patch (I'd expect this to be in the 0.5-2h range) 2.4.2 is penciled in for early 2015 (end of year is unlikely on my behalf due to 31C3 and such). Feature freeze would likely occur mid December.> I would like to suggest a couple of possibilities. > > 1. The ability to turn the feature on and off. This may not be the > best route but it may be the simplest to implement. > > 2. An option to allow metadata from the local host as well as the > source address. > > 3. The ability to specify a whitelist of allowed IP addresses.I'm partial to KISS and just put a big switch in (option 1). Just to be clear, *anyone* with mountpoint credentials is then able to mess with metadata from anywhere... We disabled this completely for a good reason (leaving it open to the administrator account).> Being able to do this on a per mount basis as well as globally would > be ideal.Not sure if I want to carry the complexity for this. It's a niche feature already, this would be a niche within a niche... Cheers Thomas
On Fri, 21 Nov 2014, "Thomas B. R?cker" wrote:> On 11/21/2014 02:21 PM, Geoff Shang wrote: >> I would like to request that this be configurable somehow. I agree >> that this is undesirable under most circumstances, but there are >> situations where this is required. > > It has been requested before and the answer is still the same, we have > it on our radar and it will happen in the future. If someone wants to > make sure it's in the $next_release, then possible avenues are: > - sending a patch (after discussing how to approach this, see below) > - sponsoring development of a patch (I'd expect this to be in the 0.5-2h > range)How much money would be needed??> I'm partial to KISS and just put a big switch in (option 1). > Just to be clear, *anyone* with mountpoint credentials is then able to > mess with metadata from anywhere... We disabled this completely for a > good reason (leaving it open to the administrator account).Oh I didn't realise the admin account could override this. This makes it less pressing, though still nice to have. Geoff.