dwc: https and password protection
-
@chrishamm said in dwc: https and password protection:
there is no file /opt/dsf/conf/http.conf on my rpi - not even a http.conf anywhere.
-
Sorry, I meant /opt/dsf/conf/http.json
-
@chrishamm said in dwc: https and password protection:
/opt/dsf/conf/http.json
thanks (though i do not plan to customize this file.)
-
@spllg had a look at https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-3.1 but microsoft world is very unknown to me. so i think i will give octoprint a try (after i have reconfigured duet3 in standalone mode).
-
I use a vpn server in my fai box, no need dor https and works well with Duet2wifi.
Why you don't want to use a VPN server in your LAN ? -
@pipersw i could but this complicates things.
-
@spllg said in dwc: https and password protection:
@pipersw i could but this complicates things.
Less complicated than do a reverse proxy with https on raspberry pi.
Just a certificate to generate and download on phone, and install VPN server and client software. In Free FAI box (french FAI) the VPN server is integrated, and in NAS Synology too.
-
@pipersw i do not want to discuss this but i feel a reverse proxy is far more flexible.
-
Is there a hostile party sniffing packet payloads on your internal network?
- If so, transport encryption (e.g. HTTPS) is a good defense.
- If you are instead trying to protect from casual misuse, a password is a good starting point.
Having said all of that, the underlying question is fairly common; perhaps the community can come up with an easy-to-install-configure proxy style solution. (I'm mostly pointing at myself, here, but if anyone else is going to work on this, let us all know).
-
This might not be super polished GUI, but the functions and examples should cover most things.
https://github.com/linuxserver/docker-letsencrypt(with wildcard certficates and dns challenge you don't even need to have a public web server to use lets encrypt with a custom domain with non public subdomains)
-
i have a working apache and configured a reverse proxy for dwc. accessing the url results in
"Failed to connect to <proxy-name>" <cr><nl>Network error"
the proxy-access-log says:
nn.nn.nn.nn - - [13/Feb/2020:14:50:31 +0100] "GET / HTTP/1.1" 200 687
nn.nn.nn.nn - - [13/Feb/2020:14:50:31 +0100] "GET /css/app.eb4376bc.css HTTP/1.1" 200 95851
nn.nn.nn.nn - - [13/Feb/2020:14:50:31 +0100] "GET /js/app.8855845c.js HTTP/1.1" 200 607246
nn.nn.nn.nn - - [13/Feb/2020:14:50:33 +0100] "GET /favicon.ico HTTP/1.1" 200 102407
nn.nn.nn.nn - - [13/Feb/2020:14:50:33 +0100] "GET /rr_connect?password=reprap&time=2020-2-13T14%3A50%3A33 HTTP/1.1" 404 154
nn.nn.nn.nn - - [13/Feb/2020:14:51:15 +0100] "GET /machine HTTP/1.1" 400 152
nn.nn.nn.nn - - [13/Feb/2020:14:51:17 +0100] "GET /rr_connect?password=reprap&time=2020-2-13T14%3A51%3A17 HTTP/1.1" 404 155
nn.nn.nn.nn - - [13/Feb/2020:14:52:15 +0100] "GET /machine HTTP/1.1" 400 152
nn.nn.nn.nn - - [13/Feb/2020:14:52:16 +0100] "GET /rr_connect?password=reprap&time=2020-2-13T14%3A52%3A16 HTTP/1.1" 404 155
nn.nn.nn.nn - - [13/Feb/2020:14:53:15 +0100] "GET /machine HTTP/1.1" 400 152
nn.nn.nn.nn - - [13/Feb/2020:14:53:16 +0100] "GET /rr_connect?password=reprap&time=2020-2-13T14%3A53%3A17 HTTP/1.1" 404 155the first 4 gets succeed whale all the others fail.
-
Activating HTTPS is necessary if someone wants to create a Progressive Web App that communicates directly with the printer.
-
@ernstc said in dwc: https and password protection:
Activating HTTPS
It'll likely never be just "activating" HTTPS on a duet board, unless in combination with some sort of Raspberry Pi or other more resourceful system to act as a reverse proxy for the Duet. The Duet3 with the Raspberry Pi should be able to do it (and the new Duet2 that are on the drawing board might also support working with a Raspberry Pi (or other SBC with compatible GPIO). But it doesn't make sense to re-invent the wheel and instead just use nginx or similar.
-
@bearer I was just trying to point out that is something needed for some scenario, in any way, even if we are in our own private network. There is no need to "reinvent the wheel".
-
-
-