Could you try if the hosted test-version has the same problem?
https://laserweb.github.io/LaserWeb4
(Unfortunately this version has no server communication)
https://laserweb.github.io/LaserWeb4 works fine (Chromium browser)
I can see the Tools options to load/save configurations.
FYI, this is the link I’ve been using so far for my
git clone https://github.com/LaserWeb/lw.comm-server.git (as per https://github.com/LaserWeb/lw.comm-server/wiki/Manual-Installation-(RasPi))
Ok. The hosted version is not the newest code, so we now know that this older version would work.
I will try to find out the exact version so you can get those files to copy into your apps folder.
Thanks a lot.
Ok, found it. You can get the hosted version from the gh-pages branch of LW4:
I’m not sure if the server sonnection will work if these files are copied to the app folder of lw.comm-server, but it’s worth a try.
And don’t forget to clear the browser cache, because the former webpack files could be taken from the cache.
I’ve been caught with cached data before so always flush the cache!
No success with the files you provided. Drop-downs for Macros and Tools are none responsive,
As far as I can tell, these are the only options that read/write files on the client system. Don’t know how relevant that fact is.
Any further suggestions of things to try hre?
It doesn’t make sense that the online version (gh-pages) works, but the same webpack files don’t work, when served from lw.comm-server (nodejs).
You could try to serve the webpack files from a separate webserver on the pi.
I’ll give that a try.
As I mentioned in an earlier post. If I use Chromium on the Pi itself (console or vncserver) and connect to to localhost:8000, it does work. It’s only when connected remotely that it fails. I have tried different versions of Chromium and Chrome on my desktop (Ubuntu) to test this.
I was curious, if you found a way to fix it for the time being. Because I have the same issues.
Copying over the gh-pages version did not work for me.
I probably have the same problem with lw.comm-server on my Raspi 3 with Raspian Buster, with Node v10.19.0, npm 6.13.4.
When accessing the Raspi from my Chrome (80.0.3987.149 on Mac), the Settings -> Macros and Settings --> Tools do not open - although they do open on https://laserweb.github.io/LaserWeb4
I’ve noticed, that I also get some errors on the browser console:
Maybe they’re related to the problem?
PS. Sorry for posting 3 times - it’s not possible to put 3 images into one post for newbies 
Unfortunately I’m limited to my home office and don’t have access to my development environment.
Thanks for the fast reply! It’s not urgent. I was just playing around with LW4 and a portable China laser for our FabLab.
Sorry to bump an older discussion, but I’ve been looking into this too. It is happening to me when I use any Chrome v85; but a old chromium v73 install (chromium is the community port of Chrome) install still functions properly and the tools+macros can be selected.
I’d also noted that the ‘Camera’ selection entry (right before ‘Macros’) was also misbehaving; adding a known good url failed, the devices list was unpopulated.
Comparing the console of the two confirmed to me that the issue is actually happening in the Camera menu section, and the tools and macros are affected simply because they are processed after that. In the console log I see:
Uncaught TypeError: Cannot read property 'enumerateDevices' of undefined
at VideoCapture.getDevices (video-capture.js:194)
at VideoDeviceField.componentDidMount (webcam.js:28)
at ReactCompositeComponent.js:262
at measureLifeCyclePerf (ReactCompositeComponent.js:73)
at ReactCompositeComponent.js:261
at CallbackQueue.notifyAll (CallbackQueue.js:74)
at ReactReconcileTransaction.close (ReactReconcileTransaction.js:78)
at ReactReconcileTransaction.closeAll (Transaction.js:207)
at ReactReconcileTransaction.perform (Transaction.js:154)
at ReactUpdatesFlushTransaction.perform (Transaction.js:141)
I assume that this crashes out whatever script was supposed to populate the Tools and Macros panels before it gets to them.
And when I search on that it appears that trying to enumerate the camera devices when not on a secure or localhost connection is no longer possible. I find issues such as this:
To test this I set up a quick-n-dirty https proxy and accessed my install via that.
The Macros and Tools were back! Unfortunately I couldn’t get the server connection to pass through the proxy so I’m not sure how to work around in the long term.
I have a fully buildable from source LW4 and comm-server setup I can play with if anybody has any suggestions/modifications/patches that I could try. But this sort of Web/JS/Node debugging and fixing is way beyond my skills,
Alternatively; whet is the state of running LW through a secure proxy? Does anyone do it successfully? if so, how 
Could the comm-server do this natively?
2 Likes
This is a quick workaround you can apply via a browser flag. It restores the missing menu entries; but wont be available forever and results in a ‘you have messed with my security settings’ nagbar.
Quick summary; Chrome is closing potential security holes, and LaserWeb is falling afoul of that when used in a client-server config. eg, you connect from a laptop to a remote Pi/Host plugged into the controllers USB.
To Workaround: Go to the following url:
chrome://flags/#unsafely-treat-insecure-origin-as-secure
And enable it; then enter in the box below it the full URL, including the http:// part and port number, that you use to connect to the Pi/Host.
Read and accept the warnings; And restart the browser via the big blue button.
What we are doing is allowing the LaserWeb site itself to be treated as ‘secure’, eg served via https, when in fact it is not. because we are restricting to this single internal site the actual actual risk this presents to us is trivial. If you cannot trust LaserWeb you should probably be uninstalling it right now.
When chrome starts there will always be a nagbar on the initial tab reminding you that you have this flag set, you can click it away but not disable it.
The Webcam preview, Macro and Tool menus should now be restored. If not; check you have the correct full URL and no typos in it. My server is accessed via http://10.0.0.110:8000/ So I saw:
And set the flag like this:
Resulting in Joy:
TL:DR summary; Chrome is closing potential security holes, and LaserWeb is falling afoul of that when used in a client-server config (eg, you connect from a laptop to a Pi/Host running next to the machine itself and plugged into the controllers USB.
In particular they have recently closed the ability to enumerate (list) the webcams on a browser unless you are on a secure connection. The Javascript encounters an error and exits. This can be worked around in code (I will have a go myself, it looks trivial) but until that lands there is a good alternative.
Finally: using Secure web hosting is not much of a solution since the insecure comms between LaserWeb and the comms server are now blocked as insecure comms from a secure client; resulting in a catch-22 when it comes to solving this via a secure proxy? Unless I am missing a config option to encrypt server connection too.
1 Like
I wonder whether building LW into an Electron app would give easier control? Probably better than setting insecure configuration for system-wide Chrome in any case.
1 Like
That is always an option, lots of LaserWeb users are doing that anyway (running it as a local app while plugged into the controller) and this issue does not affect them.
For those of us who want LW as a web service it will affect us, and electron is not part of the solution to that. The correct solution is adding logic in LaserWeb so that it does not enumerate cameras unless it is allowed to, this restores the current status-quo, at the expense of losing local cameras on the client machine.
Looking forward it would be nice to get LaserWeb able to serve itself securely without breaking the comm-server connection. We need to make the comms-server protocol able to work via https, and that will take Java skillz beyond mine.
Other issues, whether it is done natively, or via a lightweight local proxy (I favor the former) and handling self-signed certificates, etc. need resolving for this. But that is do-able.
The incredibly limited scope of the security exception is the only reason I would suggest it publicly in the first place. If you understand this, and still dont want the risk then wait for the code fix to arrive.
2 Likes
Not tested yet from chrome on windows; only from chromium + chrome on linux.
1 Like