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.
Related
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
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)
I am developing a web app, that needs to run on android mobile device's browser and, communicate with a mobile app which is installed on that device.
The web app need to communicate through ajax calls to localhost (to the android mobile device) to retrieve data from the mobile app.
So far I tried fetching from: http://localhost, http://127.0.0.1, http://10.0.2.2 and none of them worked.
I succeeded only by getting the device IP using webRTC and fetching from this IP.
Is there another way to do this?
If I understand correctly you are trying to inspect development on your android device, you need to use Google Chrome, just open localhost on your mobile device and connect via usb to your computer, then use the remote device tool.
Follow the tool link: https://developers.google.com/web/tools/chrome-devtools/remote-debugging
If you're on the same network you can use your internal IP address. If you're using windows you can use ipconfig and if you're a MAC user you can use ifconfig.
After you found your internal IP address append the port number that your server is running on internalipaddress:port and start making requests there.
I set up a service worker for a static web application that needs to work on mobile phones. I'm using react/webpack2 for this application.
Service Worker installs and works greatly when I open the application via desktop, but when I try to visit the application through mobile, it does not install.
When SW finishes installing, it gives you an alert message ("onInstalled");
https://abo-deg.surge.sh (here is an example)
https://abo-deg.surge.sh/survey/background
https://github.com/strongharris/sample (sw.js located inside src, main entrypoint: src/index.js, webpack.config)
The alert message shows up via desktop, but not on mobile browsers.
Am I missing something? Is there a different way to set up a service worker for mobile web applications? Any resources, or tips, or guesses would be greatly appreciated.
I think the answer is pretty simple. Your server does not automatically transfer you to https://abo-deg.surge.sh when you type abo-deg.surge.sh on your mobile.
I was able to run it on Chrome Mobile by typing full URL with https://
Service worker API is available only for websites running over HTTPS, because
Having modified network requests wide open to man in the middle attacks would be really bad
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
Please keep in mind, that your code will work only on these browsers, so don't expect it to work on iOS
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.