Chrome Now Blocking Web App HTTP WiFi Provisioning

Questions & Answers
1

A heads-up for anyone implementing Web App + HTTP WiFi provisioning in their products (like the mDash Smart Light example): Chrome support is going away

Here’s the unfortunate scoop:
In Chrome 94 Google released a new implementation of the Private Network Access (formerly CORS-RFC1918) spec. This restricts your ability to access an unsecure local address from a remote site.

In the Smart Light example the mDash ESP32 webserver exposes HTTP endpoints via 192.168.4.1 If you try to access this from a external site (e.g. a Web App hosted on mDash or elsewhere) Chrome will block it as a CORS violation. The error will look something like this:

Access to XMLHttpRequest at 'http://192.168.4.1/GetKey' from origin 'http://mysite.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space

You can read more about this in-depth here along with a temporary Chrome flag workaround, but that workaround expires in May 2020. Firefox and Safari seem to be working (for now).

  • For those of you planning new products, strongly consider a different way to provision your WiFi credentials on your devices
  • For those that already have products in the field, be prepared for some tech support calls on this

Either way, the days of Web App-based HTTP provisioning appear numbered.

-AD

2

Just noticed this recently as well, I thought it was maybe just me!

Side note - I’ve not seen the same issue when using a captive portal solution for device configuration, it allows the HTTP connection without any warning messages

3

A captive portal solution should be OK since it does not violate the Private Network Access spec:

  • If you you have a publicly-hosted Web App that tries to access the private network address of your ESP32 device (which is what the mDash Smart Light reference design does) that’s when you’ll see a Chrome CORS violation
  • If you’re using a captive portal, all accesses are contained within the private network so there is no violation

More details here.

With all of that in mind, a Captive Portal provisioning approach seems like a good way to go for a new design and avoid CORS issues which are not going to go away.

The challenge here is that in addition to provisioning WiFi credentials onto the device, you also need to register the device and the associated customer object with mDash. Not sure how to do this with a Captive Portal approach… would be great if Cesanta ( @lsm @Sergey_Lyubka ) could weigh in here.

-AD