I've discovered that I can't access a LAN webserver using the URL reporter in Chrome (and my main browser Vivaldi which is chrome based)
But it still works from Firefox
If I just type the URL in the browser address bar - it works but just not when trying from Snap!
Googling seems to point to a change late last year in Chrome
bh
July 5, 2022, 9:38pm
2
Do you control the server? Does it publish a CORS policy?
Dariusz has answered on a different thread so carrying on discussion back there
You can add CORS header
[scriptImage11186157]
Chrome@Win10 v 103 - this MB script works for me with local HTTP server@D1 Mini. The built-in led can be toggled with [untitled script pic - 2022-07-06T011509.679] or by a browser.
[scriptImage9960790]
Snap! served by http URL http://extensions.snap.berkeley.edu/snap/snap.html
But... without the CORS headers, it works either way for me.
.
It can be updated to use current version of the serial library.
A new extra header to control access to private networks has been introduced.
Access-Control-Allow-Private-Network: true
.
But...
May 2022: Chrome 102 rolls out to Stable. The deprecation trial ends. Chrome blocks all private network requests from public, non-secure contexts.
It's not clear to me if "Access-Control-Allow-Private-Network: true" will bypass this limitation.
So Snap! should be served from HTTPS URL (secure context) with "mixed content" enabled.
And/Or ESP32/PICO board with the local server running HTTPS endpoint should be used.
Dans Chrome 94, dans le cadre de la spécification d'accès au réseau privé, Chrome abandonne l'accès aux points de terminaison du réseau privé depuis les sites Web publics non sécurisés. Poursuivez votre lecture pour découvrir les actions...
Yes, that is what I've found out as well
It'll be interesting to see if the Snap! team are willing to do the "mixed content" thing that you are suggesting and whether it would actually work.
It's a browser setting or command line switch - it changes every few months ;(
Starting the fresh one, not shared, Chrome process with the "--allow-running-insecure-content --disable-web-security" should do the trick.
To enforce the new process, kill the other instances of Chrome, or use the switch
"--user-data-dir=\some_directory"
"--profile-directory=\other_directory"
[edit] Didn't work for me the first time I tried it. But cleared the cache and it now works
It wouldn't be a good workaround in a school/college as I doubt the IT dept would let people run Chrome that way!
[edit2] Now it's not working again!
Maybe I fooled myself that it was working!
[edit 3] Yep - I think when I thought it was working, I had clicked on another tab in another browser and not the Chrome one
Attempt failed ...
It may work with
"mixed content" enabled
Snap! served over HTTPS
server@D1Mini programmed to send CORS and PNA headers
Access-Control-Allow-Origin: *
Access-Control-Allow-Private-Network: true
I'm not able, right now, to pull all the strings at once...
.
[Edit.1] Even if mixed content is enabled, the service worker (sw.js) will block subsequent calls, by design.
So, for boards without HTTPS server, MQTT (public or local server) seems to be the simplest way.
[Edit.2] This scenario works for me in Chrome.v103@Win10
Disable then relaunch chrome://flags/#block-insecure-private-network-requests
Run HTTP Snap! http://extensions.snap.berkeley.edu/snap/snap.html
Lan server can be accessed over HTTP with eg.
I closed and re-opened Chrome - put chrome://flags/#block-insecure-private-network-requests into address bar - set it to disabled and it works
[edit] I did the same in my normal Vivaldi browser and that also works now
system
Closed
August 5, 2022, 8:01pm
11
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.