[TangerineSDR] Webserver for local host

[Rob Wiesler]

On Tue, Dec 03, 2019 at 12:16:45 -0600, David Witten via TangerineSDR wrote:
> I do not see much need for complication with more than very lightweight
> 'frameworks'.

I'll agree a little more strongly - we must actively avoid anything
"full featured".  The reason my company's system has problems with
Django is not because it serves pages slowly, but because Django takes
forever to import on a tiny SBC, and makes you import it as part of
basically all maintenance tasks.

> I would propose an architecture where the localhost runs a simple web
> service loop.  This loop would be launched at boot and principally serve
> two pages - one page that just provides status information without
> authentication.  The other would be a page requiring login by the
> owner/controller of the localhost that allows control of services and
> presentation of data to the owner/controller of the device.  All data would
> be served over secure, certificated connections.  All interaction would be
> through small, purpose-built service handlers that autostart but allow
> management through the owner/controller's page.

Caveat one: "Secure, certified connections" can be approximated, but not
achieved.  HTTPS really only works (and even then, not well) for
Internet-facing installations where access to the physical hardware is
carefully limited.  It is effectively impossible to get properly-signed
HTTPS certificates for embedded systems not under our physical control
in the field and behind NAT.  We can (and should) make the TangerineSDR
generate self-signed certificates, but then we still have a MITM issue,
plus now our users' web browsers are screaming at them that something is
wrong.  I imagine that first-time setup via the web interface will
basically only happen on a private access point or wired connection, and
most users shouldn't have too much of an issue re-accepting the
self-signed certificate every year or so when it expires and the web
server regenerates it, especially if the instructions are well-written,
but that's not the same thing as "secure".


Caveat two: Having the webapp talk to too many different processes is
probably a bad idea.  I think Bill envisions at least one master control
process - even if it makes sense to split all the various knobs between
different processes, the webapp should still probably only talk to the
master control process (although it might also need a background mule to
save some dynamic session state between worker threads).


> In many cases, such as the transfer of bulk data to the central repository,
> connections would be best handled using Web Sockets or some similar
> mechanism directly by the service process with only lightweight progress
> reporting directed through the Web interface.

Caveat three: Web Sockets are a really bad idea, especially in Python.
That effectively limits us to using Twisted and Autobahn, and either one
of those is a complete nightmare to be avoided at all costs (I won't get
into the nonsense we've had to put up with at work to make it halfway
usable).  TLS over TCP is pretty easy, not to mention sane, and it can
be worked into basically any event loop.


Apart from those small details, I think that would definitely be the
architecture to shoot for.


> These are just my thoughts right now, I'm sure that I can come up with more
> opinions if anyone wants to hear them.

I'm really hoping to free up some time this decade so that I can
actually get some work done for the project instead of just coming up
with opinions. :)