135 replies to this topic

[anudanan]

Erik,I i think that is an good idea to eliminate all auth checks from the streamproxy and use the given user/pw from the URL to auth the get connect to OWIF. That must work in all situations in which OWIF is used for tuning or providing the data ot a stream or movie stream

[Erik Slagter]

I think all should be fixed now:

 

https://github.com/e...d9a5e211d6916aa Don't send authentication to OWIF for the web/stream URL request.

 

It's no longer required, we're originating the request from
localhost. And OWIF no longer requires authentication for this URL from
localhost.

 

https://github.com/e...17ea4cf0572ad44 Use OWIF config "auth_for_streaming" instead of "auth"

 

Now we no longer need authentication for the OWIF itself (see previous commit), the subject of the authencation should be streaming, not access to OWIF itself.

 

It will be updated in the develop branch. If anybody wants to test in 7.0RC, please wait for the develop nightly build to finish and I'll post the binary here, you can overwrite it and test. If OK I might add it to the RC, depending how soon we're going to release.

[Erik Slagter]

 OWIF now sends a different URL

#EXTVLCOPT--http-reconnect=true 
#EXTINF:-1,SAT.1 HD
http://-sid:96741def930294655f1cb53cbf296309f3104b4ec615619f444b5c55f642d9e9@192.168.1.43:8013/1:0:19:EF74:3F9:1:C00000:0:0:0:?bitrate=1000000?width=720?height=576?aspectratio=2?interlaced=0

That works with for example VLC if I stream without transcoding, but with transcoding the streamproxy can´t find the given user in the passwd file. I´ve seen the error message in /var/log/message

This is no valid http. Streamproxy does not know to handle it. But I don't think you'll need it after last changes.

[Erik Slagter]

 

 

OWIF should fix this by whitelisting the above mentioned URL and then streamproxy never needs to authenticate against OWIF.

 

We can whitelist about any URL but this one:

It's the auth check for the original streamproxy ...

 

Just pass the credentials you got from your client to your streamproxy's HTTP GET request for this URL:
If it succeeds, you can consider auth successful, if it fails with 401, just pass the error to the client.

 

You can then even remove all other auth checks from your streamproxy.

It's the ONLY url that streamproxy needs/uses.

 

I suggest combining another request to solve this:

 

Clone this url to another similar url and add language tags. At the moment streamproxy can't select the proper language for the user because the information is missing, OWIF only supplies pids and purpose (audio/video/pmt/pat).

[Erik Slagter]

Erik,I i think that is an good idea to eliminate all auth checks from the streamproxy and use the given user/pw from the URL to auth the get connect to OWIF. That must work in all situations in which OWIF is used for tuning or providing the data ot a stream or movie stream

You are forgetting a few "small" things.

 

- the situation where streamproxy acts as a proxy (...) for enigma/xtrend style transcoding/streaming. Then it will still need to have OWIF credentials (even though it's not using OWIF at all there)

- streamproxy is not married to OWIF. It's perfectly fine to start a streaming/transcoding session without ever going through OWIF. I never use OWIF for this purpose just start mplayer/mpv/vlc with the proper URL + service and you're good to go.

[SpaceRat]

We can whitelist about any URL but this one:
It's the auth check for the original streamproxy ...
 
Just pass the credentials you got from your client to your streamproxy's HTTP GET request for this URL:
If it succeeds, you can consider auth successful, if it fails with 401, just pass the error to the client.
 
You can then even remove all other auth checks from your streamproxy.

It's the ONLY url that streamproxy needs/uses.

Yes, that is valid for pliproxy and streamproxy (To make things easier, I will just refer to your proxy as pliproxy and to the orignal streamproxy as streamproxy) ...
... just that you want exactly the opposite behaviour that streamproxy needs.

OWIF needs to enforce auth on this one URL even on local connections, as it's the way streamproxy handles auth.
pliproxy wants no auth here, because it's implementing its own auth method (which can not handle transient logins as a side effect) and ignores the credentials it got from the client.

 

I suggest combining another request to solve this:

It can not be resolved.
Opposite behaviour can not be combined.

Things would be much easier if you just did as described: Remove your auth code and use that in OWIF by simply passing the credentials to that GET request.
Everything would just work: Streaming without auth, streaming with auth and Linux user credentials and streaming with auth and transient logins.

 

Clone this url to another similar url and add language tags. At the moment streamproxy can't select the proper language for the user because the information is missing, OWIF only supplies pids and purpose (audio/video/pmt/pat).

I don't know how to do this.
But you can do it here: https://github.com/E...llers/stream.py

And as I bet you will refuse to stick to simple solutions that just work, we can also clone /web/stream to /web/plistream as yet another extra sausage for PLi.

[SpaceRat]

- the situation where streamproxy acts as a proxy (...) for enigma/xtrend style transcoding/streaming. Then it will still need to have OWIF credentials (even though it's not using OWIF at all there)
- streamproxy is not married to OWIF. It's perfectly fine to start a streaming/transcoding session without ever going through OWIF. I never use OWIF for this purpose just start mplayer/mpv/vlc with the proper URL + service and you're good to go.

That works as well if you let OWIF do the auth by passing the credentials ...

There are two reasons why OWIF adds transient logins for itself:
- WebTV won't work without as VXG as a browser plugin offers no way to enter credentials and OWIF doesn't know valid Linux credentials on its own anyway (and there is no decent way to let it know about them)
- When clicking any streaming URLs inside OWIF, it's much nicer if playback can start instantly, without the media player having to ask for credentials first (And some mobile clients don't support asking for credentials at all)

[WanWizard]

 

 OWIF now sends a different URL

#EXTVLCOPT--http-reconnect=true 
#EXTINF:-1,SAT.1 HD
http://-sid:96741def930294655f1cb53cbf296309f3104b4ec615619f444b5c55f642d9e9@192.168.1.43:8013/1:0:19:EF74:3F9:1:C00000:0:0:0:?bitrate=1000000?width=720?height=576?aspectratio=2?interlaced=0

That works with for example VLC if I stream without transcoding, but with transcoding the streamproxy can´t find the given user in the passwd file. I´ve seen the error message in /var/log/message

 

This is no valid http. Streamproxy does not know to handle it. But I don't think you'll need it after last changes

 

 

It is valid HTTP ( http://<user>:<pass>@URI ). This is exactly why the original streamproxy need auth to be active, it needs OWIF to deal with this fake login / session emulation.

[SpaceRat]

OWIF now sends a different URL

#EXTVLCOPT--http-reconnect=true 
#EXTINF:-1,SAT.1 HD
http://-sid:96741def930294655f1cb53cbf296309f3104b4ec615619f444b5c55f642d9e9@192.168.1.43:8013/1:0:19:EF74:3F9:1:C00000:0:0:0:?bitrate=1000000?width=720?height=576?aspectratio=2?interlaced=0
 

That works with for example VLC if I stream without transcoding, but with transcoding the streamproxy can´t find the given user in the passwd file. I´ve seen the error message in /var/log/message

This is no valid http. Streamproxy does not know to handle it. But I don't think you'll need it after last changes

It is valid HTTP ( http://<user>:<pass>@URI ). This is exactly why the original streamproxy need auth to be active, it needs OWIF to deal with this fake login / session emulation.

I think Erik was referring to the question marks as parameter separator.
But about the basic auth you are right.

Gesendet von meinem SM-N950F mit Tapatalk

[WanWizard]

Ah, missed that, we've addressed that quite a few months ago: https://github.com/O...0b91d5ad058b22d

[anudanan]

It will be updated in the develop branch. If anybody wants to test in 7.0RC, please wait for the develop nightly build to finish and I'll post the binary here, you can overwrite it and test. If OK I might add it to the RC, depending how soon we're going to release.

If you send the streamproxy binary I can test it on my boxes for streaming without authentication. it must be work now with my workaround.

 

But there are some things open around streaming with auth if OWIF creates transients passwords and die URL goes then from the client to streamproxy. So I think acutal streaming without auth would be ok but with auth there is some work to do to have a good user experince with OWIF and auth streaming over streamproxy (also with some apps which uses directly the OWIF m3u8 file with transients logins)

Edited by anudanan, 8 January 2019 - 07:36.

[Erik Slagter]

I have resolved it this way:

 

- added a patch to our OE that reverts the revert from Schimmelreiter; for our OWIF package, there is no need to have authentication on the web/stream page and we don't use nor care about legacy implementations.

- kept the changes in streamproxy so it no longer tries to authenticate to that page

 

Problem solved.

 

You'll need to both the adapted OWIF and the streamproxy for this to work, from our develop branch. It's not going into the release. But I think there will be a 7.1 pretty soon and that will have the changes.

 

I am not going to discuss with Schimmelreiter, because he is always "right", there is simply no sense in discussion. I am going to spare me the time plus irritation and have myself a nice fun night.

[SpaceRat]

At least you didn't disappoint me.
I never expected anything else than a dirty hack, after all it's still OpenPLi.

[anudanan]

Eric, can you send me the new streamproxy binary so I can test it with the non patched OWIF on my box so stream without auth.

 

For the auth problem I have the following idea.

 

 

if openwebif has enabled auth for streaming then the url contains

http://-sid:pw@ip-address .....

 

In this setup the OWIF will also check the auth if streamproxy connects OWIF (without auth is only able if auth for streaming is of)

 

I think if you see an user/pw which you can´t auth with the passwd, there is the possibility to connect the OWIF for your neccessary actions exactly with this -sid:pw pair instead of none. 

I have seen in the OWIF soruce that OWIF checks in streaming with auth setups these -sid:pw users and streamproxy need a user:pw in that setup to connect OWIF. 

 

If the connect is successfull, the -sid:pw user is auth, if the connect fail, the user ist bad

[anudanan]

If make an other patch  in stream.py on my OWIF.

 

because today streamproxy can´t handle the .sid:pw authentication for streaming, my modified stream.py no creates a know passwd user (not root), which I´ve installed for OWIF. Now it is possible to stream with authentication because the given URL of OWIF with  the passwd know user:pw work now with streamproxy.

 

It is a workaround but for me an it works now, but I prefer the idea of my last post because of transient logins.

 

Now I can use with OWIF and streamproxy and direct streaming with all combinations of auth and streaming auth

Edited by anudanan, 8 January 2019 - 21:35.

[anudanan]

I´ve found out that only the last OWIF without the last revert in httpserver.py works with all authentication combination.

 

I think the reason is here in streamproxy.py

# #3: Access is from localhost and streaming auth is disabled - or - we only want to see our IPv6 (For inadyn-mt)
        if ((host == "localhost" or host == "127.0.0.1" or host == "::ffff:127.0.0.1" or host == "::1") and not (request.uri.startswith("/web/stream?StreamService=") and config.OpenWebif.auth_for_streaming.value) or request.uri == "/web/getipv6"):
            return self.resource.getChildWithDefault(path, request)

You get only access from local process if auth_for_streaming is false or the URL is starts not with /web/stream?StreamService, 

I´dont know, what exactly this code means and why it is in OWIF. Do you know? If not, i ask the OWIF developer. Maybe that is a bug

 

 

 

The next reverted code from what I have today on my box works in all authentication setups, if the requested URL starts with /web/stream?StreamService

# #5: Access is from localhost and requesting stream?StreamService
# This is required by external applications (e.g. streamproxy) that require enigma2 to setup a service (tuner/demux).
# The URL in itself does not allow streaming so it is safe to always allow it to localhost.
if (host == "localhost" or host == "127.0.0.1" or host == "::ffff:127.0.0.1" or host == "::1") and request.uri.startswith("/web/stream?StreamService="):
return self.resource.getChildWithDefault(path, request)

[anudanan]

Or maybe the reason for the check in httpserver.py is that exactly if streaming with auth is enable and the streamingservice must be requested with auth (user/pw auf passwd user or transient users). That means streamproxy must give the user/pw given in the URL from the client to OWIF if streamproxy requested the service

[SpaceRat]

Or maybe the reason for the check in httpserver.py is that exactly if streaming with auth is enable and the streamingservice must be requested with auth (user/pw auf passwd user or transient users). That means streamproxy must give the user/pw given in the URL from the client to OWIF if streamproxy requested the service

You got it.
It resembles the behaviour of the Dream Webinterface here, which behaves that way because of Dream's streamproxy (not pliproxy).

While all distros (except Dream of course) have switched away from the old Dreambox web interface, some continue to use streamproxy (for a reason, as the current integration of streamproxy into E2 itself breaks auth).

This is what will happen with Erik's newly introduced bug:
streamproxy will succeed with its HTTP GET request, no matter what streaming auth is set to, making streamproxy believe auth was successfull. As this is the only auth check in the whole streaming process, all streaming ports become wide open without auth.
Not saying that a plain basic auth makes a good protection, but opening streaming entirely without auth is even more painful.

[SpaceRat]

because today streamproxy can´t handle the .sid:pw authentication for streaming, my modified stream.py no creates a know passwd user (not root), which I´ve installed for OWIF. Now it is possible to stream with authentication because the given URL of OWIF with  the passwd know user:pw work now with streamproxy.

When introducing the transient logins, I considered your approach as an alternative but decided against it.

Multiple reasons speak against this approach:

• We provoke a situation in which OWIF "knows" (= has in memory) the credentials of a valid Linux user on the box. It even reveals these new credentials inside any m3u it creates.
  This problem can be limited by creating a user that can not even log in on terminal (using /bin/false as shell), but the other problems weigh even more.
• If the box gets rebooted or even just the GUI/E2 gets restarted in this situation, the newly added user remains in /etc/passwd
• Even if the box does not get rebooted or the GUI restarted, it's hard to find a place to delete that user again.
  If we delete it just after the first successful auth, switching stations inside m3u playlists (= multiple stations) will trigger auth when switching them.
  If we delete them on E2 exit, the risk that the user remains conserved inside /etc/passwd gets even higher.

Transient logins in the way they are currently implemented now don't have any of these problems:
They are worthless for SSH, telnet, ftp, ... and they become invalidated on exit, now matter how that exit takes place (reboot, GUI restart, crash, hard power off), as they only exist in RAM.

[anudanan]

I know these problems and the user has /bin/false as the login shell

But I have searched a solution for auth streaming without changing the code of streamproxy because I don´t have  openpli development environment or the neccessary streamproxy toolchain here. I can only change simpel some python code.

 

But I´m thinking about a use of my older PC to setup a linux and the rest of the toolchain to compile a complete system. If I have time I will do that

Edited by anudanan, 9 January 2019 - 12:56.