Open Bug 1410365 (dev-https-everything) Opened 7 years ago Updated 3 days ago

[meta] Improve secure context development experience

Categories

(DevTools :: General, enhancement, P3)

57 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: jkt, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug)

Details

(Keywords: meta)

Meta bug for secure context developer experience improvements.
Alias: dev-https-everything
Depends on: 1409841
Blocks: 1039678
Depends on: 1410368
Depends on: 1410369
Severity: normal → enhancement
Component: Developer Tools: DOM → Developer Tools
Priority: -- → P3
Summary: Improve secure context development experience → [meta] Improve secure context development experience
The real problem "little guy" developers face with secure contexts and development is their cobbled-together "local server".  Providing an easy-to-configure local server that serves files off of a local disk, and an easy-to-generate local certificate would go a long way toward solving the developer experience. It is a pain in the neck to configure Apache or IIS to run locally, and they bog down the local machine.  On the other hand, there will be some "big guy" developers that need all the facilities of Apache or IIS, but presumably they have more resources and knowledge of server configuration, and have development servers available.

For example, I develop using a Python HTTP server as my local server. It was not at all obvious how to configure it to do HTTPS, but I finally did. And then it was not at all obvious how to configure it to handle multiple requests simultaneously (which caused certain features of Chrome to hang the server), but then I finally found the right Google query and bug reports and comments to get me past that.  I deploy to Apache, but am no Apache expert for running it on my own machine. I finally figure out how to upgrade my self-signed certificate to use something more secure than SHA-1, to quiet the thousands of warnings being spewed to the web console.  None of this stuff is straightforward to the web developer that isn't also an IT administrator, and searching out all the pieces to put together to get it to work was time-consuming, even though once each piece was found, it wasn't terribly hard to perform the necessary steps.

So a light-weight server that supports multiple simultaneous requests, CGI, serves from a CWD, and comes with a tool to generate a modern self-signed certificate (maybe even generating its own internally on first use), would go a long ways towards enabling the "little guy" to be able develop comfortably using a secure context instead of complaining bitterly that secure contexts get in the way of development.

I did a survey of "light weight" server tools when I got stuck hanging my server trying to experiment with web apps in Chrome (which seems to have the lead in supporting same, hopefully Firefox will catch up soon). All the ones I found had some limitation that prevented it from being useful... one didn't support CGI, one supported CGI but only in cgi-bin, one seemed to support everything I needed, but was a library that had to be invoked from a self-written main routine, in a language I don't use, etc. So I was extremely happy to finally stumble across a comment telling me how to get my Python HTTP to do multiple requests.
I didn't emphasize in comment 1 that having this stuff be well-documented is key. It would also be handy to have easily installable CGI plugins... I suppose PHP is popular enough to be one of them, and WordPress another. Personally I use a Python back-end, although it is invoked from the Python server via CGI so the environment is a bit more like when it is invoked from Apache via CGI.

I should mention node.js... that was easy to get running on my machine, but the cheapo web hosting services don't provide it, so it isn't really an option for "little guy" developers on the low end of the spectrum.

And the other problem with low-end deployment is the extra charges for certificates and private IP addresses to support the certificates. There needs to be a solution for using HTTPS with shared IP addresses, so that web hosts can't offer teaser rates for HTTP, and quadruple them when you add private IP address and HTTPS.... today, the only solution for that is to redirect from one's own HTTP domain, to the host's HTTPS domain: instead of  http://www.mydomain.com/... you wind up with some atrocious thing like   https://www.cheapo-web-hosting.com/~accountname/...
I won't answer to all your points but this one:

> There needs to be a solution for using HTTPS with shared IP addresses,

This is possible for some time [1], the support is quite good now. 
[1] https://en.wikipedia.org/wiki/Server_Name_Indication
The "little guy" isn't your only concern here.
What about the "big guy" that has server-infrastructure with load-balancing and HTTPS termination at the load-balancer. Local dev builds will run over plain HTTP in that situation. Depending on what tech stack and frameworks are in use it can be quite a pain to configure solutions to run with HTTPS locally, and without when deployed.

You can solve that easily enough though: offer a way to white-list domains.
@Julien - thanks, I had heard of SNI. I guess the issue is whether the shared host is configured for that. Will investigate.

@r.otten - interesting. I'm "little guy" enough that I never thought about the case you mention, and while I can understand the situation and concern, the big guy should be able to configure a solution to have a (copy of) the load-balancing front end in front of the development server: testing in any other way might be useful for some things but until tested with the load-balancing front end in place, would not test everything, so deployment of something not tested with the front end in place would be risky, especially if configured differently regarding HTTPS.
@glenn
It's not a deployed internal testing environment that's the issue. The issue is with doing development work on a web solution and needing to run it locally on the workstation of the developer.

Just having 'localhost' white-listed would solve the base problem. 
(Is it already? I think this is what Chrome does, atleast...)

However, just that is not enough.
Sometimes third-party software your solution relies on a domain name and won't accept localhost. What you eventually end up with to make that work is adding a host mapping for something like `local-dev.example.com` to `127.0.0.1` and accessing the locally running site like that.

This is why a configurable white-list is a must.
Using any sort of localhost solution when testing a mobile site would require porting a proxy to each mobile operating system. Would Apple allow it?
@damian Android has a reverse proxy as part of recent versions ADB, so the Android device can be connected via USB to the host running a localhost server, and everything works. So I'm not sure what kind of proxy you are talking about porting, but maybe there are two possible proxy options.
Product: Firefox → DevTools

Just my 2¢, just allow a whilelist of domains to treat equivalently to localhost. That'll allow people on my_hostname.local mdns domains, localhost, 127.0.0.1, or whatever variant of dev.example.com that they use to work.

No longer blocks: 1039678
No longer blocks: 1569964

I think there should be no discussion at all that 1) localhost is not enough; and 2) media.devices.insecure.enabled it's heavy artillery. A whitelist or a command line switch (like --unsafely-treat-insecure-origin-as-secure in Chrome) may be a perfect solution.

IMHO all these *.insecure.enabled prefs should be removed.
Please run a local https server like nginx (Linux, Windows, MacOS) with https://github.com/FiloSottile/mkcert to test your application properly and avoid any occurences of http:// and ws://. You could also use it as reverse proxy in front of your http://127.0.0.1:port/ app.

@Jan if that were feasible that would be nice, but dictating that everyone use nginx is pretty unrealistic. And some people are already working on projects that use the webpack dev server directly or indirectly (for example create-react-app uses it under the hood and doesn't allow configuring it without creating a LOT more ongoing work for yourself).

Honestly anything that resolves to 127.0.0.1, ::1 or the like should be treated the same as localhost for the purpose of trust.

Severity: normal → S3

since 4 years, any update ? It is pretty sad to not able to run app enclosed in docker vpn, just because there is not enough wish to make our life more easy.

You need to log in before you can comment on or make changes to this bug.