Sapper: Mixed Content error when loading /__sapper__ when accessing dev server with https

[btakita]

I'm developing an app that uses Auth0. Auth0 requires https to work, even for development.

However, sapper hot module reloading does not work on Chrome & Firefox due to the mixed content error.

It seems like web sockets over a different port are being used. I'm willing to configure the url to access the hot reload service, which I can proxy through nginx or something similar.

[thgh]

Did you ever find a solution for this?

[Seb35]

I have a first proposition to deal with this issue, although it must be discussed. My working (but hacky) proposition is:

1. to reverse-proxy the connection from HTTPS port 10001 to HTTP port 10000 (e.g. with nginx)
2. to modify sapper/sapper-dev-client.js:

-        source = new EventSource(`http://${window.location.hostname}:${port}/__sapper__`);
+        source = new EventSource(`https://${window.location.hostname}:${port+1}/__sapper__`);

I aggree the port+1 is arbitrary and not a generic solution. More robust solutions include:

• either add another parameter for the public-visible dev-port (and people can configure HTTPS through the proxy), with a default to the dev-port,
• either manage the https connection inside Sapper (but this is a lot of new parameters: public certificate, private key, https versions, ciphersuite preferences, etc.)

[thelittlebug]

adding https to sapper is imho no good idea. the proxy does that job better.

but +1 for either add another parameter for the public-visible dev-port (and people can configure HTTPS through the proxy), with a default to the dev-port. that would be really helpfull

and the protocoll could be $(window.location.protocol)

[bdougherty]

I'm wondering if /__sapper__ needs to be on a separate port at all. It would eliminate the need for any extra configuration if it was served from the main server.

[Conduitry]

I had assumed we were using some third-party livereload library that needed to run its own server (on its own port), but as far as I can tell this is not the case.

[michaek]

I think there's a good argument for keeping the dev server out of the main server - you can be sure that there's not any unexpected entanglement between the dev and production servers. It seems there's already a CLI flag for --dev-port on sapper dev, but (unfortunately?) it does affect both the server port binding and the port used in the client.

I'd prefer that a way to explicitly override the complete EventSource URL, and leave it up to the user to configure the appropriate proxy settings for this case. For me, this would be setting the EventSource to /__sapper__ and then adding something like this to my nginx server configuration:

    location /__sapper__ {
        proxy_pass        http://0.0.0.0:10000;
    }

However, the service worker would also need to be modified to allow /__sapper__ to run from the same host and port as the web server (even via proxying), as it uses host and port to check whether to "ignore dev server requests".

[t8g]

My solution is to use http-proxy

https.js

const httpProxy = require("http-proxy");
const fs = require("fs");

httpProxy
  .createServer({
    target: {
      host: "localhost",
      port: 3000
    },
    ssl: {
      key: fs.readFileSync("server.key", "utf8"),
      cert: fs.readFileSync("server.crt", "utf8")
    }
  })
  .listen(8080);

And a simple task change in package.json

    "dev": "run-p dev:*",
    "dev:https": "node https.js",
    "dev:http": "sapper dev"

[webdeb]

Another possible solution would be to let the developer override the sapper-dev-client.js file, seams to be simpler, then introduction configuration options etc.

[webdeb]

Or, let the developer override the connect function through a dev.js file. Eventually also other functions, if something like this (custom env needs) pops up again... It's definitely not going to happen, but maybe... ;)

[Arstman]

My solution is to use http-proxy

https.js

const httpProxy = require("http-proxy");
const fs = require("fs");

httpProxy
  .createServer({
    target: {
      host: "localhost",
      port: 3000
    },
    ssl: {
      key: fs.readFileSync("server.key", "utf8"),
      cert: fs.readFileSync("server.crt", "utf8")
    }
  })
  .listen(8080);

And a simple task change in package.json

    "dev": "run-p dev:*",
    "dev:https": "node https.js",
    "dev:http": "sapper dev"

this solution works for me, but only the event source don't work, to make both the site and event source dev server works, i add one more proxy server like below:

base on @thgh https.js file:

```
const httpProxy = require("http-proxy");
const fs = require("fs");

httpProxy
.createServer({
target: {
host: "localhost",
port: 3000
},
ssl: {
key: fs.readFileSync("server.key", "utf8"),
cert: fs.readFileSync("server.crt", "utf8")
}
})
.listen(8080);

httpProxy
.createServer({
target: {
host: "localhost",
port: 10000
},
ssl: {
key: fs.readFileSync("server.key", "utf8"),
cert: fs.readFileSync("server.crt", "utf8")
}
})
.listen(10001);

```
meanwhile, change the sapper-dev-client.js file as @Seb35 did:

source = new EventSource(`https://${window.location.hostname}:${port+1}/__sapper__`);

then it should works fine with both https site and https sapper dev server.

[jvanst]

I added <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> to fix this issue in Chrome.

[jpinho]

The comments on this PR are a bit cryptic for me, it there any outcome of this? What's on the roadmap? Is it safe to say that at the moment Sapper Dev server does not support HTTPS? Is this something we will want to fix eventually?