Setup:
I have an ESP32 running a HTTPs-Server with a self-signed certificate. It provides status information about some homeautomation-devices.
Now I built a Vue-based PWA that is served from a public HTTPs-Server with a regular certificate.
The PWA requests data from the ESP in the local network via https://192.168...
After installing the PWA on my mobile device, Chrome warns me that my PWA accesses content from an untrusted-cert https (which is perfectly reasonable for me).
As a workaround I have to do the following (only once): Access https://192.168... in Chrome, where I get the warning for 'NET::ERR_CERT_AUTHORITY_INVALID' and allow this untrusted access.
After this workaround the PWA works great with the ESP32 even after restarting and updating it.
I want to use the PeriodicSync-API to get the status from my ESP32 once a day and show a notification on my mobile device if something's not ok.
I setup the service-worker to listen for the periodicsync-event and then fetch() data from the ESP32 via https.
Problem:
This works correctly if I connect to my device via chrome://inspect/#devices and simulate the 'periodicsync'-event.
But if I leave the app alone for 12-24 hours and the regular periodicsync-event is finally triggered then fetch(...) catches an error with the following reason: TypeError: Failed to fetch
My guess (after spending many hours on that issue) is that this error relates to the untrusted certificate. It seems that chrome remembers that I agreed on the unsafe access as long as the PWA is open but it does not adopt this agreement for the service-worker.
Question:
Any ideas how to trust a self-signed-certificate in the service-worker or tell the service worker it should use the same permission as the PWA?
A no-go is:
starting browser with certain flags
using a paid long-term-certificate on the ESP32
Related
Many modern Web APIs are gated by the browser to be HTTPS only. This is good for users but can make developing painful. During development I'd like to be able to turn off that requirement just for testing.
Is there a flag I can set (about:config in firefox, about:flags in chrome) or a command line parameter I can pass in to turn off that requirement so I can test without having to setup https certs and add them to the browser?
Note: I understand the https requirement is dropped for localhost but I'm often hosting on one machine (like a laptop) and testing on another (like an Android device) or a different desktop. I know I can generate a local cert and run a server that supports https. I then have to deal with security warnings on the browsers (invalid cert) and/or add the private certs to all the devices OR I have to register a domain solely for the purpose of getting a valid cert via letsencrypt. For my own dev I'd just like to temporarily turn off that check in the browser if possible. Of course what I actually serve to users will be https but during dev if I could turn off that requirement things would be so much easier.
In my particular case I'm trying to use WebXR so dev happens on my laptop but actual testing happens on an Android device where the page is served from my laptop.
One solution suggested here is to use Chrome's port forwarding
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server
That works for Chrome desktop to Android
On your desktop you tell desktop chrome what site at what port to forward to your android device at another port. That site can be a server on the internet or a server running locally on your desktop. On the android device you can then access that site at http://localhost:<port-you-specified>. https requirements are dropped for locahost host so you can now use the APIs that were restricted otherwise.
Chrome has a developer setting Insecure origins treated as secure in chrome://flags/, this is a text field where you can add a list of origins treated as secure for development purposes. (Via https://github.com/immersive-web/webxr/issues/60)
Chrome allows Geolocation API access from HTTP (sans "S") loaded resources as long as their loaded from localhost or 127.0.0.1. However I would like to debug my mobile web app accessing my PC on 192.168.0.x is this possible?
I have tried loading the phone via Chrome debugging on the PC via USB but it still falls foul of the restriction. Any ideas?
BTW. The warning message has an "X" which I imagine is remove message but it doesn't work :-(
This is the only solution I could find: - Port Forwarding
You have to be tethered to a USB cable but it works.
I have a Win Store App app which uses REST to communicate with a pinpad device attached by USB. It has it's own proprietary http server/software but it seems fairly simple.
In my dev machine and on my test machine all works as expected. However, on my tester's machine it does not. The issue is that the xhr GET is failing. It just times out and returns status 0.
A simple get using a browser is successful, as is a script run in a browser (ie, ff, ch).
I have swapped out xhr for httpClient, jquery.ajax and a direct XMLhttpRequest call - all have the same result. I have tried setting location header for CORS. Tried different formats for the address (localhost, 127.0.0.1, 192... etc). The app will happily get external content (eg google.com).
Has anyone come across something like this before? I suspect it's something to do with how a Windows Store App interacts with the lan but I don't know where else to look.
By default Windows Store apps are blocked from loopback connections to localhost. By default, Visual Studio sets up an exception when debugging and you can set one up yourself for testing or for side-loaded apps with the checknetisolation tool. If your app will be deployed from the store it cannot rely on a loopback exemption.
See Using network loopback in side-loaded Windows Store apps on MSDN:
To add a Windows Store app to the list of apps that are exempt from
the loopback firewall, run checknetisolation loopbackexempt -a
-n=<package family name> from an elevated command prompt. The package family name for a Windows Store app is available from Visual Studio
via the Package.appxmanifest editor on the packaging tab.
I am using a self signed certificate for the development of an Open Layers 3 implementation.
OL3 is reading layers from a Geoserver using https://localhost:8443, and the website is being hosted at https://localhost:444. I am using Apache and Tomcat 7 for this.
This all works fine in Firefox. Though I get the initial warning about the certificate. But accepting the risk it then connects via https with no problem, and all of the content is delivered correctly.
In Chrome and IE however I am getting the following error in the console and the site isn't receiving content from the Geoserver:
https://localhost:8443/geoserver/
Failed to load resource: net::ERR_INSECURE_RESPONSE
This is associated with port 8443 which is what Tomcat is using to deliver Open Layers 3 content.
It turned out the reason is that Chrome and IE use a certificate store which it checks against to validate the certificate where as Firefox doesn't. You have to assign your self signed certificate to the certificate store for it to allow any data to be transferred through to the client in IE and Chrome.
In IE you can left click on the certificate error -> View Certificates -> Install Certificate, and then install the certificate in Trusted Root Certification Authorities Folder. Refresh and it worked for me.
I am creating a HTML 5 app that uses a .net Azure Mobile Service and coming across a weird issue when trying to login a user on Internet Explorer (and only IE): It brings up a Windows Security dialogue box with the message :
"The service (back-end url) is asking for your username and password.
The service reports that it is from Service"
Dismissing the dialogue box gives the error "Access is denied."
I've tried entering my application key for the password (as you would do when testing the api) but that did not work. I've set up CORS correctly as I can make calls that only require the application key and turned off intranet discovery. I even tried deploying to a azure website to see if was a local issue. No luck.
Chrome & firefox do not show the dialogue and does the callback as usual.
I had this same problem and used Fiddler to inspect the differences between IE and Chrome. Chrome was not presenting this credential pop-up for Azure Mobile Service credentials and IE was. It turns out it is a CORS (Cross Origin Resource Sharing) issue in IE. If you inspect Fiddler, IE will report a HTTP 401 Unauthorized response for a cross domain GET call to AMS.
The solution is to go into the Azure Portal to your Azure Mobile Service and go into the 'Configure' tab. Within here you can set up and add the valid CORS URLs. This does include any addresses that are valid to call your service. It could be public and might be *. If you have it restricted make sure you include any 'localhost' addresses as well that might call the service during local development using IE.
For more information please see the following:
Cross-origin resource sharing