135 replies to this topic

[anudanan]

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 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, can you post the binary from streamproxy from the developer branch for testing  the new streamproxy with 7.0RC and OWIF without my workaround for config.OpenWebif.auth_for_streaming

Edited by anudanan, 10 January 2019 - 10:26.

[WanWizard]

Which box?

 

Not that it will help, Erik and I had a long discussion last night about the issue at hand, and it is now clear what and where the problem lies.

 

In April of 2017, Joerg introduced the "-sid" session cookie in OWIF, only tested against the streamproxy used in OpenATV, not realizing (or not bothered by) the fact OpenPLi uses a streamproxy that Erik wrote from scratch and therefore is functionally equivalent but logically different.

 

Because of that, the "-sid" session cookie authentication has never worked in OpenPLi. Erik wasn't aware of this change, he doesn't follow OWIF development, and didn't receive any info from the OWIF developers they made this functional change.

 

Had they tested and researched this properly, they would have noticed that it not only doesn't work in OpenPLi's streamproxy, it also doesn't work in other cases as well. For example, transcoding on 8001 is done entirely inside Enigma, and that code doesn't know how to deal with the "-sid" user either, as it doesn't use the pass-through hack via the VU+ transstreamproxy. So on an Xtrend/Mutant with OpenATV, the "-sid" session cookie won't work either.

 

Resume, to make authentication on streaming working properly, both with a valid linux account and with an OWIF session cookie, changes need to be made to both the streamproxy and enigma itself (and to OWIF as a result of those changes).

[anudanan]

uno4kse, ARM

[WanWizard]

uno4kse, ARM

Attached Files

•  streamproxy_2+git142+1ba6911-r0.0_vuuno4kse.ipk   108.63KB   4 downloads

[anudanan]

I´ve tested that new streamproxy ipk and it works now fine on my 7.0rc with the config.OpenWebif.auth_for_streaming instead of config.OpenWebif.auth

 

But today it works only with the OWIF from the 7.0 feed enigma2-plugin-extensions-openwebif - 1+git3249+03c0b4f-r0.0

 

 

If I use the newst httpserver.py from OWIF GIT in which this revert is include

https://github.com/E...b1c570ab7a810e3

 

then it is only possible to stream without auth. If auth for streaming is enable and a valid passwd user is used for auth, it doesn´t work now.because the http connection from streamproxy to OWIF fails.

 

So there is an open issue for auth with trancode streaming 

 

But now the solution for the better parameter is fine

Edited by anudanan, 10 January 2019 - 14:00.

[WanWizard]

It works with the OWIF we build because that includes the patch from Erik. The "-sid" session cookie doesn't work (and has never worked).

[anudanan]

I mean auth streaming  with normal passwd users, not with -sid user.. That works fine with the OWIF from your feed, I think the OWIF from four feed includes the code to enable streamproxy to setup the service without auth anymore. But the newest OWIF httpserver.py server doesn´t  have that code, it is reverted in the GIT. So if you take in future the next snapshot from the OWIF GIT, there is a problem with also with passwd users for transcodes streaming.

[WanWizard]

No, because, as I said, we've patched that in our build process: https://github.com/O...be374fcee904ce5

 

Next step is to see how streaming and transcoding can be integrated in Enigma so there is a single codebase for streaming, and when that is done, implement authentication properly. This is quite an undertaking which requires quite a bit of skill and low-level Enigma knowledge, so it might be that we'll add a temporary workaround to our streamproxy to make that "-sid" session cookie work.

[anudanan]

Now I have understand, thx

 

Do you have planes to use -sid transient users in future. That is a nice idea from secure point of view for auth streaming starting from OWIF (and APPs which use OWIF and which can´t ask about user/password):. The user has  allways different passwords like a onetime key

Edited by anudanan, 10 January 2019 - 14:41.

[WanWizard]

We see the use-case of some sort of session cookie, which you need to generate secure URL's in m3u8 files, to avoid exposing credentials, to avoid password prompts in streaming clients using these m3u8 files, and to avoid a total failure to stream if the client doesn't support HTTP basic auth, which is what @Spacerat pointed out earlier in this thread.

 

Whether or not that will be in its current form will probably depend on the to-be architecture and design.

[anudanan]

Thx for sharing informations

[Erik Slagter]

The obvious first-glance solution would be to delegate authentication always to OWIF, but that will have some consequences which I need to consider carefully. One of them is that I have a demand that streamproxy can work standalone without OWIF. There is no functional nor technical requirement that transcoding be initiated by OWIF, it's just the most user friendly option so commonly used. That means some sort of authentication must remain inside streamproxy. And then a few other considerations as well.

 

Also note that the option "allow authentication for streaming" in OWIF is not functional and has never worked, in OpenPLi for the following reason:

- for transcoding on "streamproxy" transcoding type receivers, the streamproxy does not understand the session cookie (-sid)

- for transcoding on "enigma" trancoding type receivers, the streamserver in enigma does not understand the session cookie (-sid) as well

- for streaming, the enigma streamserver is also used, which, again, does not understand the session cookie.

 

Even if I would adapt streamproxy to be able to handle the OWIF session cookie, there would still be two cases (#2 and #3) not covered. For that you would need to set and enable authentication for streaming/transcoding in enigma itself.

 

The changes needed for the session cookie will probably mean, one way or another, that the solution I had for for anudanan's case can probably no longer be supported. Anyway I think the combination of OWIF auth disabled and streaming auth enabled is a jar full of snakes and something you'd really not should be wanting (even if the use of a certain app dictates it).

Edited by Erik Slagter, 10 January 2019 - 17:32.

[SpaceRat]

Resume, to make authentication on streaming working properly, both with a valid linux account and with an OWIF session cookie, changes need to be made to both the streamproxy and enigma itself (and to OWIF as a result of those changes).

Interestingly, besides the fact that those transient logins were introduced by me, your analysis is 100% correct.

But an important side note would be that transient logins are only used in situations where things are borked either way, that means without them it wouldn't work for the cases you mentioned either.

[SpaceRat]

I mean auth streaming  with normal passwd users

That has never been affected.

[WanWizard]

Interestingly, besides the fact that those transient logins were introduced by me, your analysis is 100% correct.

 

Then I stand corrected, I based my remark on https://github.com/E...502f3b56bf79cad.

[SpaceRat]

One of them is that I have a demand that streamproxy can work standalone without OWIF.

You yourself pointed out that the external app pliproxy (or streamproxy) can't work without it at all, as it has to perform a http GET to that URL.
So for pliproxy or streamproxy that is nothing that really has to be considered.


If you are really interested in a solution for the built-in streaming in E2, I would be more than happy to help.

I made these considerations:
Option 1: Just let the streamserver try the http GET, even if it doesn't need it.
Option 2: streamserver.cpp should be able to get knowledge about currently valid transient logins, e.g. through a non-saved config value. It could then consider them in addition to the existing Linux users when doing basic auth.

Both options are valid for OWIF as well as the old Dream webif (in case anyone installs it manually), as OWIF just behaves Dream webif compatible.
The only difference is, that Dream's webif doesn't use any transient logins, which doesn't harm neither option 1 nor option 2.

[WanWizard]

If you are really interested in a solution for the built-in streaming in E2, I would be more than happy to help.

 

Yes, we are. Transcoded streaming (live and file) that is, standard streaming is already implemented in E2.

[SpaceRat]

Yes, we are. Transcoded streaming (live and file) that is, standard streaming is already implemented in E2.

If I'm not entirely wrong, the streaming inside E2 already is for non-transcoded and transcoded live and recording streaming, at least on all boxes that support it.
The pliproxy is just for Vu+ (and maybe Gigablue), isn't it?

I'll not add any C++ code in streamserver.cpp myself, just to make that clear. I would never do such evil to our users
I can just describe where the problem is and point potential ways to solve it (finally).
I can also support necessary changes in OWIF, as long as they don't break backwards compatibility (Because OWIF is neither OpenPLi- nor OE-A-only, it will have to continue to work with other distros as well).

I would be more than happy myself to get rid of streamproxy, but for more than a half decade it has been the only way to make IPv6 and auth fully functional.
It's about time to solve that and so far only the lack of IPv6 has been addressed.

[Erik Slagter]

 

One of them is that I have a demand that streamproxy can work standalone without OWIF.

You yourself pointed out that the external app pliproxy (or streamproxy) can't work without it at all, as it has to perform a http GET to that URL.
So for pliproxy or streamproxy that is nothing that really has to be considered.

Not quite. I could quite easily change to an implementation where access to OWIF is not required by getting the stream data from the enigma streamserver instead. The only reason I choose not to do it that way is that it's slightly more efficient to get it from the demuxer directly. I think the intention of my statement was quite obvious, still you choose to be ignorant just to be able to show off your arrogance.
 

If you are really interested in a solution for the built-in streaming in E2, I would be more than happy to help.

Erm, no thanks really, we may be skeptical, for good reasons, we're not dumb, actually.

[Erik Slagter]

 

If you are really interested in a solution for the built-in streaming in E2, I would be more than happy to help.

 

Yes, we are. Transcoded streaming (live and file) that is, standard streaming is already implemented in E2.

"xtrend" style transcoding is also handled exclusively by the enigma2 streamserver.

 

IMHO there is only "fits-all" solution and that is, what should have been done ages ago, but where chronically lacking time, extend the enigma streamserver with Broadcom style transcoding and get rid of all (tran)streamproxy's altogether. And that's why I don't feel like putting much effort in yet another workaround for something that's fundamentally broken. OWIF should limit itself to presenting the user with a list of services + URL's (either encapsulated in m3u or not, I don't care) and there it's involvement should end. With Broadcom transcoding inside enigma as well, that will be possible.