693 replies to this topic

[SpaceRat]

how come it only works when openwebif auth is off?

You might want tot thank SpaceRat for that, I just found out.

Keep in mind that I'm not the original author of the OpenWebif.

Bottom line, the openwebif options do not do what they suggest (imho).

It has always been that way.
Streaming auth can only be enabled and working if there is auth enabled for the OpenWebif itself, because else there is no auth resource added to the listener at all.

The only thing wrong in OpenWebif:
The option "stream auth" should be grayed out and shown as disabled if there isn't auth enabled for the webif itself.

 

I'll revert the change I made for this a couple of days ago and then it'll probably work.

Do whatever you want.

A plain revert will just switch back to the old error, I'm too lazy to search the bug report on it here inside this thread. Nobody seems to care ...

I gave up any hope you three will ever understand the mess you produced when you started to override plugin code inside E2 itself.
All this crap is a ticking time bomb, the next explosion will come as soon as someone uses the Dream Webif or no Webif at all ...

Actually to get rid of all bugs currently (re-)producable, you will have to create a pretty long and/or condition, taking these elements into account (all bool):

- old Webif installed
- config.plugins.Webinterface.enabled
- config.plugins.Webinterface.http.auth
- config.plugins.Webinterface.streamauth
- OpenWebif installed
- config.OpenWebif.enabled
- config.OpenWebif.auth
- config.OpenWebif.auth_for_streaming
- (config.OpenWebif.port == config.plugins.Webinterface.http.port)

Until you
- either find the proper relation between them all and add them to streamproxy and E2 internal streaming
- or just revert to the only real clean state of having the active webif on port 80 handle auth
this thread will grow and grow and grow.

In the first case it will be recreated or grow again as soon as someone comes up with another web interface ...

But don't listen to a state certified engineer, just keep ignoring me.

[SpaceRat]

PS: Don't forget to give me -1 for my postings.
It would confuse me if anyone on this forum would suddenly stop shooting the messenger ...

[Erik Slagter]

For all you guys having problems with authentication the last few days, update tomorrow and check again, it may work now. I reverted the check for "authentication for streaming" to "plain authentication", this should solve some problems.

 

The change has not (yet) been included in the internal stream server (streaming), I await the author's fiat.

[колбаскин]

What about mobile phone on port 8002?

Edited by колбаскин, 14 May 2014 - 19:33.

[SpaceRat]

For all you guys having problems with authentication the last few days, update tomorrow and check again, it may work now. I reverted the check for "authentication for streaming" to "plain authentication", this should solve some problems.

As I already mentioned, it's an AND condition.

(isOpenWebif_installed && config.OpenWebif.enabled && config.OpenWebif.auth && config.OpenWebif.auth_for_streaming)
isOpenWebif_installed = fileExists /usr/lib/enigma/Python/Plugins/Extensions/OpenWebif/plugin.py

If any of the above conditions is NOT met, there might be no listener at all on the port configured for OWI or it might not be requiring auth (if not config.OpenWebif.auth_for_streaming).

But even if ALL of the conditions above are met, it still might be it's not OWI listening ...

[колбаскин]

 - How work transcoding on PC

 

How fix work on mobile????

[SpaceRat]

As I already mentioned, it's an AND condition.

(isOpenWebif_installed && config.OpenWebif.enabled && config.OpenWebif.auth && config.OpenWebif.auth_for_streaming)
isOpenWebif_installed = fileExists /usr/lib/enigma/Python/Plugins/Extensions/OpenWebif/plugin.py

If any of the above conditions is NOT met, there might be no listener at all on the port configured for OWI or it might not be requiring auth (if not config.OpenWebif.auth_for_streaming).

But even if ALL of the conditions above are met, it still might be it's not OWI listening ...

Once you have managed to consider all of the above conditions (Incl. the setting not being physically there, but just working like being set to $whatever due to internal defaults), you can add the second bunch of conditions:

(isOldWebif_installed && config.plugins.Webinterface.enabled)

If these two conditions are met, it's not OWI listening on port 80 but the old Webif.

So for consistency with known behaviour (Just contact port 80 rather than to make messy assumptions), you have to gather the auth/stream auth settings from old Webif in this case.

However, if the previous condition is met
&& (config.OpenWebif.port == config.plugins.Webinterface.http.port)
then OWI isn't even listening with http on ANY port, let alone the one in config.OpenWebif.port:

The old Webif gets initiatized before OWI (For whatever reason ...) and hooks the port set for it.
OWI will then fail to hook the port but continue.

So in this case you do not only produce a consistency problem, but would be really reading the wrong webif's settings ...

The complete condition for auth on/off would be something like:


isOldWebif_installed = fileExists /usr/lib/enigma/Python/Plugins/Extensions/WebInterface/plugin.py
isOpenWebif_installed = fileExists /usr/lib/enigma/Python/Plugins/Extensions/OpenWebif/plugin.py

auth=0
port=80

# If old Webif is installed, use its settings for stream auth
if (isOldWebif_installed && config.plugins.Webinterface.enabled) {
auth = (config.plugins.Webinterface.http.auth && config.plugins.Webinterface.streamauth)
port = config.plugins.Webinterface.http.port
# only if old Webif is NOT installed use OpenWebifs setting
} elsif (isOpenWebif_installed && config.OpenWebif.enabled) {
auth = (config.OpenWebif.auth && config.OpenWebif.auth_for_streaming)
port = config.OpenWebif.port
}

For the moment, this should cover all imaginable variants of WebInterfaces used and their settings.

In other words:
It's idiot-proof but only until someone comes up with a better idiot.

Have fun.

[Erik Slagter]

@SpaceRat in other words, as far as I am concerned, streaming with authentication is "use at own risk". Due to the inherent lack of safety, we're not going to any length to get it 100% always working.

[SpaceRat]

@SpaceRat in other words, as far as I am concerned, streaming with authentication is "use at own risk". Due to the inherent lack of safety, we're not going to any length to get it 100% always working.

Well, as I said, the one and only clean solution is to resemble the behaviour of the original untranscoded streamproxy.

For untranscoded streaming:
1. Remove the auth guessing mess out of E2 code for its built-in streaming port 8001
2. Re-Add the original streamproxy binary

If you want to feel better about redundancy: Make the internal streaming port configurable/disableble (Spelling?).
Internal Streaming and streamproxy streaming might well co-exist ...


For transcoded streaming:
1. Rename to transproxy to avoid confusion with the other streamproxy ...
2. Simply reproduce the behaviour of the old streamproxy to try auth via localhost:80
Maybe you should just skip auth if there is nothing responding on localhost:80 to make transcoded streaming without any webif possible.
3. Optionally add a "no-auth" option for port definitions to bypass auth on this port (for local use, with auth still enabled on other ports for remote use¹)
This would enable such a setup:
listen = 8002:transcode
listen = 8003:transcode
listen = 8004:transcode,no-auth


The only "unclean" thing about the original streamproxy's behaviour is that it requires the webif to always listen on port 80, but that is absolutely nothing compared to the config/setup guessing mess we got into by removing it.

Do NOT:
... add the en-passant auth of external streamproxy into E2s internal streamproxy. You would once again wed a plugin to E2 (E2 would no longer stream properly if the user wants no webif at all).
Once again: The sole purpose of external streamproxy has been and still is to make auth through a webif possible without having E2 to mess with plugin configs.
... try to use the user defined http-port of the oldWebif/OpenWebif directly, the guaranteed listener on localhost:80 will never go away as the plugins are supposed to work on any E2 and not only on OpenPLi.
The attempt to do so would end in a config guessing mess. Just accept the listener on port 80 as a convention.



¹Yes, it's unsafe.
But nobody will give a flying f*ck, the sole purpose of transcoded streaming IS remote use.
You can only hope users will create additional users so they do not reveal the root-credentials to WireSharks.

Edited by SpaceRat, 15 May 2014 - 12:06.

[Erik Slagter]

@taboune, does transcoding work with today's update? For streaming we might take another approach to a solution.

[SpaceRat]

@taboune, does transcoding work with today's update? For streaming we might take another approach to a solution.

You should have asked Marc83 ...
For him it didn't work with proper setup, for taboune it didn't work with wrong setup.

Valid:
auth=yes
stream_auth=yes
= Auth on Webif, incl. streaming

also valid:
auth=yes
stream_auth=no
= Auth on Webif, but not for streaming

also valid:
auth=no
stream_auth=no
= no auth at all

not valid (but possible):
auth=no
stream_auth=yes
= will behave like no+no

The last setting simply doesn't make any sense:
How should there be auth on streaming if there is no auth resource added to the Webif in the first place?

The OpenWebif plugin should prevent this setting combination by graying out the "stream auth" option if auth is entirely disabled.

However, this wrong setup being possible is an OWI limitation/bug, you should not read the wrong setting just to work around the problem of a single user with a wrong setup, at the same time breaking it for anyone with the legal cmobination auth=yes / stream auth = no.

BTW: The same limitation already existed in the old Webif ...

[delavega]

@taboune, does transcoding work with today's update? For streaming we might take another approach to a solution.

Yes! port 8002 now works with auth!

port 8001 still work (no auth)

[колбаскин]

Yes! port 8002 now works with auth!

port 8001 still work (no auth)

 

8002 work on mobile phon Android?

What need to do?

[SpaceRat]

OWI: Cleanup config

So the possibility to configure impossible setups has been removed.

[Erik Slagter]

The exact meaning of both options is still a mystery to me. With this commit three combinations can appear:

 

1) authentication off, streaming auth off

2) authentication on, streaming auth off

3) authentication on, streaming auth on

 

What is the rationale of 2)? And what does it imply technically? As long as the url /web/StreamService:80 requires basic authentication in both case 2) and case 3) I don't see the point in having the "streaming auth" option?

 

IIRC the /web/StreamService:80 url does not give an "unauthorized" reply when expected auth is missing from the request, so the streamproxy MUST know in advance whether auth is required. Even if it did, I don't really feel like having streamproxy doing trial-and-terror.

[SpaceRat]

The exact meaning of both options is still a mystery to me. With this commit three combinations can appear:
 
1) authentication off, streaming auth off
2) authentication on, streaming auth off
3) authentication on, streaming auth on

Good.

The fourth case:
4) authentication off, streaming auth on
was possible to set, but OpenWebif handled it like case 1, as there can't be auth without auth ...

After the latest commit, case 4 will additionally be fixed to case 1 inside the settings, so that anyone else reading the settings will not make false assumptions ;->

However, until you really change and save anything, the "impossible" case 4 can still remain inside user configs ...

 

What is the rationale of 2)?

Uhm, actually none.
But I bet I would earn screams of protest if I remove it.

The original idea might have been:
Streaming to the outside doesn't really work, most internet lines can't handle the bandwith necessary for this.
So it's practically used only internally and internally you might want to have no auth (no children, no auth ...).

The webif itself however might be opened to the outside world (I wouldn't, you wouldn't, but face the facts, it is opened to the outside world often enough) and thus the user might want auth there while having no auth for streaming.

And what does it imply technically?

Simple:
It skips auth if the access is coming from localhost:

if (host == "localhost" or host == "127.0.0.1" or host == "::ffff:127.0.0.1") and not config.OpenWebif.auth_for_streaming.value:
		return self.resource.render(request)
if self.login(request.getUser(), request.getPassword()) == False:
		request.setHeader('WWW-authenticate', 'Basic realm="%s"' % ("OpenWebif"))
		errpage = resource.ErrorPage(http.UNAUTHORIZED,"Unauthorized","401 Authentication required")
		return errpage.render(request)
else:
		return self.resource.render(request)

See that "return self.resource.render(request)" can be reached on two paths:
1. Accessing from localhost with stream auth disabled
2. Succeeding auth

There you can also see why the impossible setup works, although it makes no sense:
While it does NOT skip auth for accessing from localhost (As config.OpenWebif.auth_for_streaming is enabled), it grants access to the ressource anyways as self.login always returns true if auth is entirely disabled.

As long as the url /web/StreamService:80 requires basic authentication in both case 2) and case 3) I don't see the point in having the "streaming auth" option?

Get the URL out of your brain
It has nothing to do with the URL ...

The true meaning of "Auth for streaming = disabled" is "Skip auth for ANY access from localhost".

That's why you have to be careful if you use 6tunnel, HAproxy, netcat or whatever to make the WebInterface available on another port or - before OWI could handle IPv6 itself - via IPv6:
If you use localhost as target for the port proxy, you implicitely also bypass auth for this proxy if stream auth is disabled.

IIRC the /web/StreamService:80 url does not give an "unauthorized" reply when expected auth is missing from the request,

Sure it does, see above.

You just had the wrong expectation: If auth is disabled, it's disabled, whatever stream-auth gets set to.

[SpaceRat]

The exact meaning of both options is still a mystery to me. With this commit three combinations can appear:
 
1) authentication off, streaming auth off
2) authentication on, streaming auth off
3) authentication on, streaming auth on

Good.

The fourth case:
4) authentication off, streaming auth on
was possible to set, but OpenWebif handled it like case 1, as there can't be auth without auth ...

BTW:
If you continue to insist on reading the settings and implement auth yourself based on them, keep in mind:
1. old Webif might be installed and enabled and the user would probably expect its settings to apply (Because it has always been that way)
2. old Webif has the same auth/streaming auth quirk as OWI had

The very same applies to old Webif as for the OpenWebif:
1. auth for streaming=disabled actually means "bypass auth entirely for access from localhost"
2. bypass auth for localhost can be (virtually) enabled but doesn't have any effect while auth is actually entirely disabled

Let's sing the song again:
To get out of the mess, just leave this to the WebInterface(s) by using their guaranteed localhost:80 listener.

Everything has been taken care of already:
- Stream auth is handled by the Webif listening on localhost:80
- OpenWebif co-exists with old Webif by NOT hooking port 80 if old Webif exists, as old Webif will already hook it.
- Each webif reads its own config and knows how to handle it.
- streamproxy doesn't mess with ANY settings at all but simply uses the guaranteed localhost:80 access.

Edited by SpaceRat, 15 May 2014 - 14:33.

[SpaceRat]

Oh, almost forget, last but not least:

- Anyone might create yet another Webif any time and everything will continue to work as long as he/she obeys the simple rules
1. to add a listener on localhost:80 for the streamproxy/streamproxies
but
2. not if old Webif is installed too

[Erik Slagter]

Wow, you really have too much time on your hands.

 

I am thinking of this: the /web/StreamService url does not make sense for remote hosts, at all. It sets up the demuxer device that must be read locally.

 

So rationally for this url:

- it should always allow access from localhost

- it should never allow access from remote

There is no sense in basic auth involvement altogether for this url.

 

But of course the transtreamproxy of VU+ relies on this artifact 

 

This is the only interaction the streamproxy has with the webif. It handles/checks auth itself, no need to relay that to the webif.

 

Oh BTW you should be happy a bit at least, for a week now, streamproxy uses :: for the connection to the webif instead of 127.0.0.1. I just hope no weird guys disable ipv6 or similar on their stb.

[SpaceRat]

Wow, you really have too much time on your hands.

At the moment: Yes.
 

I am thinking of this: the /web/StreamService url does not make sense for remote hosts, at all. It sets up the demuxer device that must be read locally.
...
But of course the transtreamproxy of VU+ relies on this artifact 

Yepp.

Because this approach, while appearing to be like going through a horse's ass to get to its mouth, is a simple and effective way to involve the Webif and its auth mechanism without
- having to know how it is set up
and
- how it works
and also
- which Webif is offering it.

This is the only interaction the streamproxy has with the webif. It handles/checks auth itself,

Which is the cause of all this current hassle.

Oh BTW you should be happy a bit at least, for a week now, streamproxy uses :: for the connection to the webif instead of 127.0.0.1. I just hope no weird guys disable ipv6 or similar on their stb.

That's nice, however it will break interaction with the old Webif, which doesn't listen on ::1 but only on 127.0.0.1
It will also break with setups where a Python without IPv6 support is involved or forks of OWI are used where IPv6 hasn't been enabled yet, or Twisted is too old for IPv6, ...

Yes, that will probably not apply to OpenPLi 4.0 on any machine, but it might apply to images based on OpenPLi ...

The inability to open streams on IPv6-only servers (e.g. other E2-boxes behind DS-lite) would have been more important to fix ...