Tvheadend

It's a big security hole. I don't want to give back the password at all through any playlists. The good players should support the standard HTTP authentication (ideally the digest one which does not transmit the password directly).

Use IP based authentication for dumb players.

Better to use
user+ip+client_id=hash
as identification

Jaroslav Kysela wrote:

It's a big security hole. I don't want to give back the password at all through any playlists. The good players should support the standard HTTP authentication (ideally the digest one which does not transmit the password directly).

Use IP based authentication for dumb players.

IP based is not an option since the client IP is not static.
I don't see it as a security hole as long as the users that were meant to be used with that method would ONLY have access to streaming (no webui/admin access) - not a huge risk...
(also to receive back the password, you need to send it first)
And there would be an option to enable/disable this functionality...

So, in summary, it's not possible to setup a http streaming player which takes as input a playlist, right? (example: android "perfect iptv player", and all above smart tv iptv apps)

@luis Parada Alves
cross fingers ;)
https://tvheadend.org/issues/3699

Luis Alves wrote:

So, in summary, it's not possible to setup a http streaming player which takes as input a playlist, right? (example: android "perfect iptv player", and all above smart tv iptv apps)

In summary, the client is crappy. VLC can do user/pass authentication, any browser can do user/pass authentication, wget can do user/pass authentication..

We can talk probably about some persistent ticket hashes for those clients (valid only for HTTP streaming) but not to send any credentals in URLs.

Jaroslav Kysela wrote:

We can talk probably about some persistent ticket hashes for those clients (valid only for HTTP streaming) but not to send any credentals in URLs.

It looks good, but it is good to have some kind of management from the webui, enable and disable those clients, comments for the user, connection limits, etc.

Maybe another section near the user tab?

Pablo R. wrote:

Jaroslav Kysela wrote:

We can talk probably about some persistent ticket hashes for those clients (valid only for HTTP streaming) but not to send any credentals in URLs.

It looks good, but it is good to have some kind of management from the webui, enable and disable those clients, comments for the user, connection limits, etc.

Nope. I would just add it to the ACL entries. So, enable/disable/reset and that's all. The code will be generated automatically. The rest is about URL to get such playlists like /playlist/channels?persistent=1 or /playlist/persistent/channels (probably more readable).

Jaroslav Kysela wrote:

In summary, the client is crappy. VLC can do user/pass authentication, any browser can do user/pass authentication, wget can do user/pass authentication..

It's true that there are some "crappy" clients out there :) but it's not even the case of not supporting the authentication methods.
They do support but will only use it to save the channels from the playlist they get - once the ticket expires the client doesn't know how to play the channels again.
I use tvheadend clients as I use a TV - while zapping it's annoying to keep entering credentials once the ticket expires... (not even practical if using a tv remote).

Jaroslav Kysela wrote:

Nope. I would just add it to the ACL entries. So, enable/disable/reset and that's all. The code will be generated automatically. The rest is about URL to get such playlists like /playlist/channels?persistent=1 or /playlist/persistent/channels (probably more readable).

This seems to be a good solution.
I assume the enable/disable/reset is per user (on the user config tab).
(one might want to disable or reset the tickets just for a specific user)

Luis Alves wrote:

Jaroslav Kysela wrote:

In summary, the client is crappy. VLC can do user/pass authentication, any browser can do user/pass authentication, wget can do user/pass authentication..

It's true that there are some "crappy" clients out there :) but it's not even the case of not supporting the authentication methods.
They do support but will only use it to save the channels from the playlist they get - once the ticket expires the client doesn't know how to play the channels again.
I use tvheadend clients as I use a TV - while zapping it's annoying to keep entering credentials once the ticket expires... (not even practical if using a tv remote).

Yep, but clients can store credentals to an own database pernamently like browsers/vlc do. So basically, the problem is not on the tvheadend's side, but we have to deal with this situation.

What if security is based on this scenario
currently
http://tvh.ip:9981/stream/channelid/1165510174

new optional way
http://tvh.ip:9981/$ip_hash/$user_hash/stream/channelid/1122334455
Salt for hash is good option, placed in user profile

and if user have enabled option, requested playlist by regular way will receive new stile playlist.
sound good realisation unknown ;)

Added to v4.3-1481-gee714fc11 . The auth code is in the password table . The playlist can be obtained through /playlist/auth/ path.

I've enabled persistent authentication for user and it automatically generated authentication code PMYEtflgGdJxsWJHQhvS+4y6AddA

I requested playlist in format http://tvh.ip:9981/playlist/PMYEtflgGdJxsWJHQhvS+4y6AddA but I am getting 400 Bad Request (HTTP/1.1 GET (1) /playlist/PMYEtflgGdJxsWJHQhvS+4y6AddA -- 400).

How do I request playlist properly via this new way?

playlist through HTTP authentication:    http://ip:9981/playlist/auth      # tvh will fetch the authcode from the passwd table
playlist through authcode:               http://ip:9981/playlist/auth?auth={authcode}
streaming:                               http://ip:9981/play/stream/channelname/CHANNELNAME?auth={authcode}

I fixed some bugs and added playlist URLs to the buildin help in v4.3-1484-g7f841a351 .

Jaroslav Kysela wrote:

Added to v4.3-1481-gee714fc11 . The auth code is in the password table . The playlist can be obtained through /playlist/auth/ path.

is there something wrong in url?

curl http://11:11@192.168.1.222:9981/playlist/auth/channels
#EXTM3U

p.s.
Why unselectable="on" in UI?

Tested with v4.3-1484 playlist is ok (/)

(!) No information who use stream in Status > Subscription

suggestion:
(IP) - ip enabled
(HA) - http authentificated
(AC) - auth code

In v4.3-1484 when I enter playlist to VLC in format http://ip:9981/playlist/auth?auth={authcode} it still asks me for username and password.

Is this correct behaviour?

Shouldn't be playlist generated without these credentials purely based on authcode?

Hi Jaroslav,
I have tried and the playlist I get still doesn't contain the auth code on each entry.
I believe this is what kodiaq above is seeying also.

Hmmm... I believe this is only an issue with priorities.
I have observed that:
- When I use the new auth method on an IP that doesn't fall into the "no auth user" it works.
- When I use it on a machine with an IP that falls in the "no auth user" it always gets a playlist without the auth string unless it is forced as an argument.

This will return a playlist without "auth" argument if your IP falls in the "no auth user = *".
http://ip:9981/playlist/auth
http://user:pass@ip:9981/playlist/auth
(the second one should not)

This will return a playlist with "auth" argument:
http://ip:9981/playlist/auth?auth=<auth>

I believe it is fine as it is...
Thanks a lot Jaroslav!

@luis Parada Alves - Did you try new auth method in VLC (With IP that doesn't falls in the "no auth user = *")?

On my side, I need to enter username and password credentials everytime I change the channel even though persistent authentication for that user is enabled.

Therefore I still miss the point of this new feature as VLC behaves as previously with temporary ticket.

In my understanding the expected behavior should be, that if I enter to VLC link like this: http://ip:9981/stream/channelid/1?auth=PMYEtflgGdJxsWJHQhvS+4y6AddA&profile=pass than tvheadend should recognize that this request is from specific existing user that have persistent authentication enabled and should not require username and password credentials anymore.

Isn't the authcode introduction meant also as sort of username:password replacement?

I paste in vlc from no ip permited network

http://user:pass@tvh.ip:9981/playlist/auth/channels

Maby more correct is to use old url style

http://user:pass@tvh.ip:9981/playlist/channels

Option is very I mean Extremely useful with dynamic ip and tvh automatic network iptv input

p.s.
Anyone with permission to add wiki information how to use export url options

Luis Alves wrote:

Hmmm... I believe this is only an issue with priorities.
I have observed that:
- When I use the new auth method on an IP that doesn't fall into the "no auth user" it works.
- When I use it on a machine with an IP that falls in the "no auth user" it always gets a playlist without the auth string unless it is forced as an argument.

This will return a playlist without "auth" argument if your IP falls in the "no auth user = *".
http://ip:9981/playlist/auth
http://user:pass@ip:9981/playlist/auth
(the second one should not)

If user has enabled the authcode, then the playlist for the second (user:pass) URL should be with ?auth={authcode} parameters, but you must force the HTTP authentication in client (perhaps, it used the anonymous access without HTTP authentication).

Jaroslav Kysela wrote:

If user has enabled the authcode, then the playlist for the second (user:pass) URL should be with ?auth={authcode} parameters, but you must force the HTTP authentication in client (perhaps, it used the anonymous access without HTTP authentication).

Thinking more about this - I think that tvh should return 401 HTTP error code in this case to force the authentication.

Retest with v4.3-1485-gb7e8102ce . The user:pass@.../playlist/auth should work now even for the anonymous (allowed) IPs.

v4.3-1485-gb7e8102ce - New auth method works great with VLC using: http://user:pass@tvh.ip:9981/playlist/auth/channels . Great milestone Jaroslav!

Would it be now also possible to create new user account for users with dynamic IP address, which will be authenticated only via authcode?

Dumb players do not prompt for username and password and IP based authentication is not practical with dynamic IP. I think many tvh users would welcome this feature.

It's perfect now.

Thanks a lot for the quick implementation!

kodiaq kodiaq wrote:

Dumb players do not prompt for username and password and IP based authentication is not practical with dynamic IP. I think many tvh users would welcome this feature.

Just use /playlist/auth?auth={authcode} for those players...

Jaroslav Kysela wrote:

kodiaq kodiaq wrote:

Dumb players do not prompt for username and password and IP based authentication is not practical with dynamic IP. I think many tvh users would welcome this feature.

Just use /playlist/auth?auth={authcode} for those players...

If I use /playlist/auth?auth={authcode} I always get 401 Unauthorized error. I've tried to reset authcode couple of times, but no change. I've set my server for both plain and digest authentication.

Was looking closely to /playlist/auth?auth={authcode} method and noticed that it does not work for user accounts created in the past.

If I create new account and enable authcode it works straight away for that particular account.

I am running xenial version.

I noticed that profiles stopped working when requesting without auth:

Like this: (no auth)
http://ip:9981/playlist?profile=<profile>

No matter which profile I specify on the argument, it always uses the default one.

Can someone confirm?

kodiaq kodiaq wrote:

Was looking closely to /playlist/auth?auth={authcode} method and noticed that it does not work for user accounts created in the past.

If I create new account and enable authcode it works straight away for that particular account.

I am running xenial version.

@Jaroslav - Ignore my previous observation, it has nothing to do with the old or new account. It is related to the authcode itself. If the authcode consists of special characters (for example + ) than using auth method returns 401 Unauthorized error.

@luis Parada Alves - http://ip:9981/playlist?profile=<profile> seems to work fine for me. I've used pass and matroska profiles and it generated corresponding playlists.

kodiaq kodiaq wrote:

@luis Parada Alves - http://ip:9981/playlist?profile=<profile> seems to work fine for me. I've used pass and matroska profiles and it generated corresponding playlists.

It does generate the correct playlists but when playing them, it will ignore the profile selection (always uses the default profile).
Remember this is for "no auth" (global account)

Found the issue:
When "playlist" is the only argument, it is added with the '&' char instead of '?'

Possible fix:
https://github.com/tvheadend/tvheadend/pull/1190

The github seems really inconsistent those hours: https://status.github.com/messages .

Luis Alves wrote:

kodiaq kodiaq wrote:

@luis Parada Alves - http://ip:9981/playlist?profile=<profile> seems to work fine for me. I've used pass and matroska profiles and it generated corresponding playlists.

It does generate the correct playlists but when playing them, it will ignore the profile selection (always uses the default profile).
Remember this is for "no auth" (global account)

The profile should be restricted to username lines in ACL. Do you have allowed that profile for the given user?

Hi,
It's really a syntax error: if no auth or ticket are sent to the string, the profile argument can't start with '&' but with '?'.

I think github is back to normal and PR is visible now.
If not you'll be able to see what I mean here: [https://github.com/ljalves/tvheadend/commit/ad00441a72b4ba47e54ab7b037383159627e9e2c]

Fixed in v4.3-1494-g26dc2643e .

This is working perfect for me, great job!!
But I have a little problem. I use Tvheadend with an reverse proxy to watch tv on the road. If I generate the playlist it contains http:// in the url so I have to manually edit it to https://domain.domain/tvheadend... is there a way to force TVH to create the playlist with https links?

Set X-Forwarded-Proto : https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

Jaroslav Kysela wrote:

Set X-Forwarded-Proto : https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

Works! Perfect thanks :)

Hello

I use TVH for about 1 year and am very happy, especially with this Feature #5274 (authcode).

I upgraded TVH to version 4.3-1532~g409a70630 and the authentication code worked very well, but I see that TVH started responding for anonymous accesses (URL without http://user:pass@ or ?auth={authcode}).

Another point is that user Streaming profiles (Basic, Advanced and/or HTSP) may be not working.
I tried and a user with only the HTSP profile can request and receive IPTV Streaming (TCP 9981).

@Fawzi Benmoussa Kbsa - I am not able to re-create your issue. If I disable HTSP profile for certain user, of course I can still request playlist on TCP 9981, but I only get "HTTP/1.1 401 Unauthorized" error so this is acceptable behaviour. With anonymous access same reply "HTTP/1.1 401 Unauthorized". . .

kodiaq kodiaq wrote:

@Fawzi Benmoussa Kbsa - I am not able to re-create your issue. If I disable HTSP profile for certain user, of course I can still request playlist on TCP 9981, but I only get "HTTP/1.1 401 Unauthorized" error so this is acceptable behaviour. With anonymous access same reply "HTTP/1.1 401 Unauthorized". . .

Can I open a another issue?

Fausto Kbsa wrote:

kodiaq kodiaq wrote:

@Fawzi Benmoussa Kbsa - I am not able to re-create your issue. If I disable HTSP profile for certain user, of course I can still request playlist on TCP 9981, but I only get "HTTP/1.1 401 Unauthorized" error so this is acceptable behaviour. With anonymous access same reply "HTTP/1.1 401 Unauthorized". . .

Can I open a another issue?

Yes, but look to '--trace http' logs before, to check if the anonymous access in your ACLs is not activated. https://tvheadend.org/projects/tvheadend/wiki/Traces

Will xmltv export url: "http://tvh_ip/xmltv/channels" will also work with persistent auth user? can auth?auth={authcode} can be appended to thr url ?

I have checked some iptv clients with my tvh server and xmltv export by url: http://tvh_ip/xmltv/channels/auth?auth={authcode} works fine.

Thanks

Note that it should be sufficient do use http://tvh_ip/xmltv/channels?auth={authcode} URL, the /auth suffix is only required to generate playlists with the ?auth links (so it is useful only for http://tvh_ip/playlist/ URLs).

Sorry, it was my typing mistake. Correct url doesnt is http://tvh_ip/xmltv/channels?auth={authcode}