new WAPI+WUI proposal

[Brian Warner]

On 7/1/16 6:41 AM, Lukas Pirl wrote:

> It is surely a matter of taste and semantics but one could argue that
> it's a bit funny that a Web API delivers fancy JS-based HTML pages.

Good point!

> * WAPI (HTTP/CBOR only): note control, directory browsing
> * WUI (HTML/JS): HTML user interface to WAPI
> * WCD (Web content delivery? However you call it):
>   delivery of grid-stored files

Yeah. I think I'd want to enable CORS on the WAPI port (telling browsers
that it's ok for pages from any origin to make WAPI requests), and
design the WAPI to make that safe (e.g. *everything* requires a cap of
some sort, zero ambient authority). But if we *didn't* do that, there
might be an argument to put both WAPI and WUI on the same port, giving
the WUI pages permission to access the WAPI, but no other
browser-delivered pages.

> That way, the WUI could be handled as separate "app", connecting to
> the WAPI like everything else. Maybe there are even scenarios where
> you want to distribute those services over multiple machines?

Possibly, yeah. You could configure a remote Tahoe client/gateway (say,
on a VPS machine) to have the WAPI listen port on HTTPS and an external
interface (instead of defaulting to 127.0.0.1 and unencrypted HTTP).
Then maybe use a command like "tahoe webopen --token XYZ --wapi
wss://tahoe.my-vps.example.com:3457/v1", which would use a local copy of
the WUI (served from 127.0.0.1:3458) but tell it to talk to the remote
WAPI port, and take an explicit token instead of reading it from the
local basedir.

I need to look into how IPFS does this. I know their WUI equivalent is
stored in IPFS too, but I think they have two separate ports, and I
think they rely on same-origin protection for safety against malicious
documents.

cheers,
 -Brian