Also just don’t test on localhost. You can use a proper domain (or claim one in .test TLD[1] if you’re fine with selfsigned certs) and point it to localhost.
If you’re going to use any redirect flow like OAuth/OpenID you’re going to need this for testing eventually anyway.
Think self hosted Wiki/etc. I was never sure (and thusly have yet to properly implement it) what would be secure, but also a good UX. A normal auth + self signed https would be simplest I imagine, but I'm not clear if browsers widely accept that. I recall Sandstorm having issues with this area, and required a domain to fully run properly. Which seems.. complex for a minimal install requirement.
Thoughts?
1) Get a domain name for the project, e.g. mycoolwiki.tld
2) In the installer/setup provision for the user a random subdomain, e.g. d2c8116f19d0.mycoolwiki.tld
3) Use Let’s Encrypt DNS method to provision cert
4) Redirect d2c8116f19d0.mycoolwiki.tld to LAN IP
It’s not ideal because you need some external infrastructure and it assumes no DNS rebind protection.
However, if your webapp has a client and server, that is communicates via API only, you can actually do a lot better:
4) Setup local server to accept CORS requests from d2c8116f19d0.mycoolwiki.net only
5) Host client at d2c8116f19d0.mycoolwiki.tld
Additionally,
6) Make the client a PWA with offline support
and/or
6) Offer browser extension to use local copy of the client when user visits ∗.mycoolwiki.tld
Though for my use case I actually wanted to have ∗.mycoolwiki.tld/ipfs/<hash> be backed by IPFS and offer generic extension that both verifies that the IPFS gateway is playing nice and (if configured) redirect to local gateway.
Also offering Electron client instead of browser would work as well and saves you getting the cert.