Duet muti printer server anyone?
-
1.18 duet firmware
Chrome browser
Also DWC opens in the browserI just clicked done with the blank password field.
-
1.18 duet firmware
Chrome browser
Also DWC opens in the browserI just clicked done with the blank password field.
Very interesting. Close to what I'm using. Hmmm… I may have to put a debugging console log in temporarily... but... I've just changed the central dispatcher/connector to make it more reliable, so, if you don't mind, try again.
You should see "V1.02" in the block of notes, if things have successfully refreshed. (Ctrl+Shift+R).
-
V1.02 Now available.
Release Notes, 1.02:
- Speedup initial connect on page load.
- Cleanup wording around IP or HostName in several places
- Added "Disconnect and Close" button.
- Made individual line "Disconnect" buttons active.
- Added completion percentage to status while printing
Release Notes, 1.01:
- Allow hostnames (in addition to IP addresses)
- Fixed table sometimes not (re-)built properly after add or delete
-
-
Nice!
-
Everything in the above picture is real, updated from connections to real duets, and will perform the labeled actions when clicked, EXCEPT for the gray (white) buttons.
-
One little bug: under Chrome the printer names are displayed, but under Firefox it continues to show "TBD at first status update".
-
1.18 duet firmware
Chrome browser
Also DWC opens in the browserI just clicked done with the blank password field.
Very interesting. Close to what I'm using. Hmmm… I may have to put a debugging console log in temporarily... but... I've just changed the central dispatcher/connector to make it more reliable, so, if you don't mind, try again.
You should see "V1.02" in the block of notes, if things have successfully refreshed. (Ctrl+Shift+R).
Will do, I'll let you know how it works
-
One little bug: under Chrome the printer names are displayed, but under Firefox it continues to show "TBD at first status update".
Interesting. Some subtle Javascript difference, no doubt.
Thanks, I will check it out on FF.
-
One little bug: under Chrome the printer names are displayed, but under Firefox it continues to show "TBD at first status update".
In the spirit of transparency: I'd broken this updating of the name from the board in all browsers.
V1.03 now available.
Release Notes, 1.03:
Fixed a bug that sometimes prevented newly added printers from obtaining and displaying the board name (i.e. the name stayed "TBD" forever). -
Hey, it looks great! Im having an issue connecting, I added the IP for one and waited but it fails. I dont have a password on this board so I left the password blank. Could that be the issue? I have Deleted and retried a few times just to be sure. Thanks for the help.
Try 1.03 and let me know. If it still fails to connect, please do this:
- Press F12. This opens a split screen. Click on the "console" tab in the split.
- Reload the page. Ctrl-Shift-R, just to be sure.
- Wait approximately three minutes. Several messages will appear in the console. Please copy/paste and email these messages to me. Don't wait too long!
I am "danal (dot) estes (at) gmail (dot) com".
Thanks!
-
I'll try right when I get home, it will be 3 hours. I tried late last night with 1.02 to no avail.
-
Nice server. Currently I am using a split screen with two tabs. I will try this in my 7" screen with raspberry pi 3.
-
Nice work. This could be pretty handy.
Interesting to see that DWC includes a Access-Control-Allow-Origin header that allows stuff like this. Doesn't feel great that any website could pull data from my Duet if it wanted to. Or for that matter, execute arbitrary G-code, which would work even without CORS.
-
Interesting to see that DWC includes a Access-Control-Allow-Origin header that allows stuff like this. Doesn't feel great that any website could pull data from my Duet if it wanted to. Or for that matter, execute arbitrary G-code, which would work even without CORS.
Just my opinion:
The Duet server should be treated as insecure, with or without any given header, etc. For one thing, it doesn't do HTTPS, and so the password should be considered open to discovery by anyone on the same network. Traffic to and from a Duet should never be exposed outside the network segment it is on… NEVER to the public internet. It should ALWAYS be proxied with external authentication and external facing HTTPS provided by that proxy.
With regard to "Any Arbitrary Website", the code loaded from a malicious website into a browser that was already connected to a Duet (via DWC or MultiDWMC) would have to find the Duet's address. There is no (known) way to discover a Duet. (Otherwise, I'd be using it...).
Given that a Duet can't be treated as secure, then configuring toward maximum utility on the local network segment makes sense.
Again, just my opinion.
-
@Austin55:
I am much more interested to know more about duet printer server. I will wait for next updates.
About
-
A Duet Board/Firmware?
-
"Duet Web Control" that comes with the board firmware?
-
"Multi Duet Web Monitoring and Control" which is being discussed in this thread?
-
-
There is no (known) way to discover a Duet. (Otherwise, I'd be using it…).
Actually there is a way to discover a Duet WiFi if you have an Android smartphone or tablet. Look for "Find my Duet" on Google Play.
-
There is no (known) way to discover a Duet. (Otherwise, I'd be using it…).
Actually there is a way to discover a Duet WiFi if you have an Android smartphone or tablet. Look for "Find my Duet" on Google Play.
Ah, interesting… is the underlying technique usable from a browser/javascript?
And/or is the "Find my Duet" source available?
-
-
The Duet server should be treated as insecure, with or without any given header, etc. For one thing, it doesn't do HTTPS, and so the password should be considered open to discovery by anyone on the same network. Traffic to and from a Duet should never be exposed outside the network segment it is on… NEVER to the public internet. It should ALWAYS be proxied with external authentication and external facing HTTPS provided by that proxy.
I agree. I just think it's a shame that this is the case. TLS might be a bit too much to ask, I guess, but some rudimentary cookie-based authentication sounds reasonable to me. Attackers could still sniff the traffic and find the password when the user authenticates, but it's much better than nothing.
With regard to "Any Arbitrary Website", the code loaded from a malicious website into a browser that was already connected to a Duet (via DWC or MultiDWMC) would have to find the Duet's address. There is no (known) way to discover a Duet. (Otherwise, I'd be using it…).
Yep, apart from using a zeroconf address (that you would still have to guess). However, a web page could iterate through common local IP numbers (say 192.168.0.*) and the chance of finding it would be relatively significant. I don't like the idea of security through obscurity.
