make web server port configurable about anthias

[NiKiZe]

I was thinking about the possibility to change listen address as well, and thus changing from 0.0.0.0 to 127.0.0.1 and possibly using a ssh tunnel to access the server and change assets etc.

The default configuration is good to have, what happens if the configuration file is missing? all that needs to be handled nicely.
I would suggest using a separate screenly configuration class that both the server and viewer imports.

[axel-b]

I agree that having a separate screenly configuration class that both server and viewer import would make things nicer - I just found (created) a case where it would be useful (see below).

I'm not sure how far to go w.r.t. missing stuff; to better understand the situation it might help when all assumptions w.r.t. things that are supposed to be there, are made explicit, somewhere.

w.r.t. need for common/shared config class:
on a new branch https-auth-with-submodule
I have added the possibility to use https instead of http in server.py,
where I use the presence/absence of ssl key/certification file config items to decide whether to use http or https.
what I initially forgot (and still have to change): also viewer.py must then show the right protocol prefix in the URL in the splash page...

[NiKiZe]

While looking in to the resolution handling i want to achieve, the configuration class idea came up again.
With a separate class all the http/https changes should be easy to implement in only one place and used in both server and client.

I have tested most cases and don't see any drawbacks (please correct me if I'm wrong) so i created a pull request, It will create some conflicts with @axel-b's branches but i hope it is not to hard to sort.

[axel-b]

Sounds good, I'll have (am having) a look.
Merging in my branches shouldn't be a problem; I guess I'll wait with that until it gets accepted by vpetersson .

one question about the following comment in Config.py :

    #this listen directive needs to be handled in viewer,
    #  if it is 0.0.0.0 then the viewer shuld connect to 127.0.0.0 otherwise it shuld be configured adress,
    #  the same goes in server, but instead of 127.0.0.1 it shuld be the found adress.

For my understanding, It seems that this handling is not yet present in your pull request? Or did I overlook it?

[NiKiZe]

Yes, those notes are on the todo list...
Everything still works as before if the listen configuration is not changed.

The most likely use case will be setting listen = 127.0.0.1 so the server only is accessible from localhost, and then SSH tunnels is used to do any configuration, in that case everything in the pull works, (the splash screen will show a invalid address)

Any other interface/address unlikely (but vpn or other loopback interface addresses are possibilities)

Using the listen address to change splashscreen server is one other possible use case... but unlikely?

I'm working on the complete handling right now.

Edit:
... Done see additional commit in #29

[vpetersson]

While I've been reading the comments on the forum about people requesting to change the server port, I don't see the need for it. Most people who have requested this appears to have a lack of understanding of routing, and would simply want to change the port to have multiple nodes on the same network and want this to be able to do a port forwarding.

There have also been requests about changing the port from 8080 to 80 (or 443). This is a valid request. However, the problem with that as you guys understand, boils down to security. In order to use a port below 1024, the process must be escalated to root. I'm really not keen on the idea of running server.py as root, as it is both bad security practice and would require a large amount of extra work in terms of auditing the code.

Now, having the web interface bind on localhost however is an idea I like. I can certainly see that making sense in some case. Yet, I don't think this is something that would be useful for the vast majority of the users (but rather a small set of power-users).

Since this is a niche feature, I think it makes sense to utilize screenly.conf. I like @NiKiZe idea of using a 'listen', since it is widely used. If this setting is absent, we would default to 0.0.0.0 (just like it is now).

The added benefit with this would be that you in addition to binding it to localhost, also change the binding to an IP alias.

What do you guys think?

(and you're right @NiKiZe, we need to update viewer.py to check for this before trying to render the splash-screen).

[NiKiZe]

@vpetersson in #29 the configuration parameters both for bind address and port is implemented, also all necessary changes to viewer.py.

I'm almost ready to push a rebase, if it is acceptable to change the new settings module to a class instead,