I'd really like an option "noprivate" or somesuch within the 'authentication' specification which would not require a password for listener requests originating from a private network (192.168.x.x or 10.x.x.x or 172.16.x.x, etc ). Is this posssible? -- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************
Good morning, On Thu, 2016-02-11 at 10:22 -0700, Dave Serls wrote:> I'd really like an option "noprivate" or somesuch within the 'authentication' > specification which would not require a password for listener requests originating > from a private network (192.168.x.x or 10.x.x.x or 172.16.x.x, etc ). > Is this posssible?With 2.4.x (stable) you can implement something like that using the url auth system. With 2.5.x (development) this could be implemented in several ways, including url auth, client filter auth or a role that is written to exactly do that. However I strongly suggest against it. It will likely break security at some point. E.g. the ISP a friend of mine is using uses 10/8 for provider infrastructure. So it's part of 'the public net'. Another case may be the usage of Carrier-grade NAT. What about mixed infrastructure with 'public' and 'private' IP addresses mixed? This may or may not be inside depending on your definition. Also what about IPv6? It's not exactly clearer. I think a solution would always be to the exact problem. That means that you need to specify exactly what you call 'inside'. What is your exact problem? Maybe it's not about the auth itself. Like there could be a setup with two Icecasts, one bound to the outside world and one bound to the inside network that just skips the auth step at all. Have a nice day! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/icecast/attachments/20160212/7bf3d13f/attachment.pgp
On Fri, 12 Feb 2016 09:35:54 +0000 Philipp Schafft <lion at lion.leolix.org> wrote:> Good morning,Thanks for your reply. Simply, I want all connections from my players at home (2 or 3) to be done without authentication. Everyone else should require a password. So 192.168.1.x will cover those streams. Not likely my ISP will use part of that space (I will terminate service thereafter).> > On Thu, 2016-02-11 at 10:22 -0700, Dave Serls wrote: > > I'd really like an option "noprivate" or somesuch within the 'authentication' > > specification which would not require a password for listener requests originating > > from a private network (192.168.x.x or 10.x.x.x or 172.16.x.x, etc ). > > Is this posssible? > > With 2.4.x (stable) you can implement something like that using the url > auth system. > With 2.5.x (development) this could be implemented in several ways, > including url auth, client filter auth or a role that is written to > exactly do that. > > However I strongly suggest against it. It will likely break security at > some point. E.g. the ISP a friend of mine is using uses 10/8 for > provider infrastructure. So it's part of 'the public net'. Another case > may be the usage of Carrier-grade NAT. What about mixed infrastructure > with 'public' and 'private' IP addresses mixed? This may or may not be > inside depending on your definition. Also what about IPv6? It's not > exactly clearer. > > I think a solution would always be to the exact problem. That means that > you need to specify exactly what you call 'inside'. > > What is your exact problem? Maybe it's not about the auth itself. > > Like there could be a setup with two Icecasts, one bound to the outside > world and one bound to the inside network that just skips the auth step > at all. > > Have a nice day! > > -- > Philipp. > (Rah of PH2)-- ************************************************************************ * Dave Serls Littleton, CO, USA * * dashs.denver.co.us http://www.dashs.com * ************************************************************************