Icecast Streaming Media Server

[Cog]

Hi guys, newbie question:

I am testing URL user authentication but not having any joy with it as yet. I've entered the <mount> code in the conf file in the icecast user account as specified in the icecast online manual.

I'm not sure what to expect. I've listened to the channel but I've not been challenged for a password.

Does anyone know what I should expect? A pop up window asking for a user id & password?

What about if a listener is listening via iTunes? Would that pop up a challenge box?

Confused.

Thanks.

[karlH]

a popup usually only occurs if the specified listener_add script (php?) rejects the listener trying to connect. ie without the
icecast-auth-user header

karl.

[Cog]

Thanks Karl, but how does Icecast know that user has the correct user id and password to access that mount point?

I was expecting a standard user id and password challenge to gain access to a stream.

I dont understand how it decides if the user has the correct uid and password or not.

[karlH]

The whole idea of URL auth is to allow for authentication to be handled externally, typically because the criteria for auth is stored somewhere else. It also allows for the possibility that auth may be done on some other criteria than user/pass, eg session id created from a web portal. The deciding factor that icecast looks for is the header icecast-auth-user in the response from the scripts.

karl.

[Cog]

Been in the bath pondering this and wondered if this was what you were going to say. I was barking up the wrong tree.

So,

If a user can get access to a specified URL (page) then icecast will allow them to listen to the stream.

If a user has not accessed that URL the. The stream will not play irrespective of the player being used, Is that correct?

Thank you for helping out here by the way, I just need to get my head around this concept & I will be fine.

[karlH]

Not quite, the listener requests a mountpoint, and icecast will try to auth the listener details with the auth specified.

In the case of url auth, icecast will issue a url request, passing various details about the listener to see whether it should allow that listener to continue. How the script determines that verification is outside of icecast's control, it could look up a DB, it could block people from all but a single country, it may even allow all and log details.

Whether the listener has to go to a site beforehand is completely up to the site administration. An example could be, go to a web portal, generate an m3u with a temporary session id and then icecast passes those details to auth and if that session id matches what the portal allocated then ok the listener.

karl.

[Cog]

Hi Karl, thanks for this. I am using amember for authentication.

So ignoring what exactly I have set amember to accept, if I have set a URL , e.g. Http://www.mysite.com/icecast-account/mount-point.3mu for the listener to click in a web page or enter in their chosen player icecast is going to ask amember if that URL is ok for listening to that mount point?

If the URL of the location of the 3mu file is not located at the URL specified by the auth then I am thinking icecast will get a negative response and the listener will be rejected.

Am I on the right lines?

Thanks.

[karlH]

it sounds like you are confusing an m3u with the script. An m3u is just a playlist format like pls. The listener_add url inside of the auth is run from a web server so if your http://www.mysite.com/icecast-account/mount-point.3mu contains

http://myicecast.com:8000/stream

and /stream on icecast has

[Cog]

Thanks Karl, nearly there.

So do I locate the playlist file in the URL that is listed in the "listener_add" value ?

I'm wondering if the 3mu playlist file is emailed to someone or posted on some hack portal somewhere why will it be rejected by this process.

[karlH]

the listener_add url is just for the auth script, the m3u is just to get the stream, they are 2 different parts. remember there is a listener to icecast connection and an icecast to auth server connection, that is why there are 2 urls to think of. The htpasswd auth is just a local file to in that case there is only the 1 url (the stream url).

karl.

[Cog]

Hi Karl, so taking a step back for a moment.

I have a stream I want to only allow certain people to view. I want to offer the way to listen to that stream via their internet connection and a player of their choice.

What do I put on a website to present this secure way of listening to my secure stream so that only those people I want to listen to that stream can do so, and others, who I dont want them to listen to it, will not be able to.

I appreciate this is fundamental, but having gone around the houses here and listened to a few guys explain the detail of the technology, I am still left not understanding, in simple language how I do this today.

[karlH]

You definitely need the stream authentication for that, using user/pass combinations or some sort of session identifier is a decision you need to make.

user/pass combinations can be done with htpasswd, a simple, quick mechanism using a local lookup of the username/password against a file to match.

Others may find that htpasswd lookup is not adequate so url auth was added to allow for passing that decision to something external, typically a php script running off a backend web server. The script allows for specifying your own authentication rules as icecast only requires a yes or no style of response.

I don't know if you have something in mind that requires url auth but from the discussion so far, htpasswd is more than adequate for your needs.

karl.

[Cog]

I've set this up exactly as I understand amember to work with the icecast plugin and have now left a new ticket with the amember guys as I am none the wiser why it isn't working. At present, and having edited the icecast user account's server.conf to point to a membership subscription product in my amember installation I am still able to listen to the stream without being challenged. So from what you have said Karl I get the idea I should expect a user ID and password challenge. I will let the amember guys know this is what should be happening. Thanks for your help n

[Cog]

I've flound a missing " in the auth URL address so now waiting for that to be changed on the server. Hopefully after that a listener will get challenged when trying to listen to the mount point.

[Cog]

Its working missing " in the code.. duh.

So now I get the uid and pw challenge when I open in iTunes (for example)

But I dont get challenged on the iphone using Quicktime.

I am wondering if anyone know what clients support the user authentication challenge? anyone had any experiences with this?

THank you

Guy