I'm trying to test out Google's PaymentRequest api on a local website running in my android emulator. However, when I do
var paymentRequest = window.PaymentRequest(//some object here//);
I get the following error
"Error: Failed to construct 'PaymentRequest': Must be in a secure context
Now, PaymentRequest DOES run on localhost and https, but running it from a port on an android emulator, where the uri is 10.2.2.01:8000/myUrlHere will fail becuase that's not localhost. Any ideas as to how to get around this?
PaymentRequest must be used on secure context, which is one of:
HTTPS.
Localhost.
Local file on disk.
http:// 10.2.2.01:8000 is not a secure context, so you can't use PaymentRequest there. Try one of the following:
https: //10.2.2.01:8000. (The SSL certificate must be valid. This means the lock icon in the URL bar should be green. You can get one from https://letsencrypt.org/, for example.)
https: //localhost:8000.
file:///sdcard/index.html
If you own an Android device, there's a way to test your site by connecting the device via USB cable and serve from localhost. Try this:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/
If you don't, you may want to try this tool with the emulator:
https://ngrok.com/
ngrok allows you to serve from localhost proxying from ***.ngrok.com domain.
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
I am currently trying to develop a PWA, however, I can't work out how to get it hosted over the local network? It works fine when connecting to localhost from the host machine but will not connect from any other devices on the local network. I believe it might be to do with the fact that the PWA is served over HTTPS and I have tried setting up Open SSL but I'm not too sure whether this is actually the correct idea to get it served over the local network? Thanks in advance.
I mostly use two options:
a) Chrome Remote Debugging + Port Forwarding: This will allow you to port forward your website to your mobile device
b) Netlify Dev: This will give you a temporary URL with https you can use to access from mobile device
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.