[Icecast] Circumvention of authentication when using fallback mounts

[Michael Franzl]

On 05/13/2017 03:12 PM, Philipp Schafft wrote:
> Basically the client structure would need to keep track of which sources
> the client was attached to in form of a stack. This is important as
> there can be fallbacks of fallbacks (and there are valid reasons to
> build something like that). A pure 'original mount' thing may result in
> unexpected behavior. That being even more true if there are multiple
> paths from one mount to another.

Sounds about right. Here is another unexpected but similar scenario,
which is the current behavior of Icecast:

If /music is a declared fallback stream of /voice, and a client connects
directly to /music, then, when /voice comes online, the client is be
moved to /voice, even though the client has never requested to hear voice.

I think the simplest solution would be when Icecast, for each client,
constructs a chain (a simple 1D array) of mounts he has 'fallen though',
and then, when any parent mount of this chain comes online, moves the
client up to that parent, but no further than that. If a client is moved
back up the chain, all 'lower' parts of that chain can be forgotten.

Regarding authentication in this scenario, Icecast should not
remember/cache any previous authentications. As soon as a client is
moved to *any* mount (caused by falling through or moving back), it
should do a fresh authentication request. For example, permission to
listen to a stream could have been revoked from the time a client first
connects, then falls through to a fallback, to the time when he is moved
back to a private stream.


> Speaking of a solution:
> I think this is a very valid request for 2.5.x. I would open a ticket
> for it if you don't want to do it yourself. But 2.5.x is still beta. On
> the other side 2.4.x will only updated with (security or regression)
> fixes. So I don't see it entering 2.4.x (unless tbr, our Project Manager
> decides otherwise).
> 
> Would a update for 2.5.x help you?

This would definitely help, yes, and I would appreciate if you could
create the ticket in your system.

> I hope that this mail was at least helpful by confirming the problem.

Yes, it was.

Thank you,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170513/e245c6c0/attachment.sig>