APIs that abandoned http
These years, it is impossible to develop software without https. The apis in the web standards in recent years all require https, otherwise they will strike! They include but are not limited to:
Notification: system notification
Geolocation: geographic information
Storage: storage/cache
PWA: Progressive Web Application
Payment Request: Payment
Clipboard: Clipboard
ServiceWorker: daemon thread
MediaDevices: Media devices
Crypto: cryptography tool
Generic Sensor: Sensor
Bluetooth: Bluetooth interface
Authentication: Authentication
WebXR: Virtual Reality
Presentation: Screen sharing
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts
Information Sources
These apis cannot be used normally under http, especially chrome has the most stringent requirements. The above APIs must be used only when the entry document and asynchronous resources are all https, otherwise the following prompt will appear.
However, during development, it is not so easy to deploy https locally. I want the browser to recognize that the security of the website is not as simple as imagined. Especially when accessing the local server, chrome always shows a red exclamation mark. I have tried the following methods for many years. All failed:
Naturally, fake certificates won’t work
Issuing a self-signed certificate to localhost or ip address was rejected by the system
Modify the hosts file and install the certificate, but the browser does not recognize it (chromium has its own certificate manager)
Adjusting chrome's preferences (chrome://flags/) is OK but very troublesome
Is there a simple and stable method that is in line with the thinking habits of ordinary people? There is always no clear answer on the Internet. Until a few days ago, when I played VisualSVN Server, I finally discovered the standard method.
4 types of addresses for local servers
| IP address |
domain name | |
| local |
127.0.0.1 |
localhost |
| The internet | Network card IP |
CPU name |
The local server can be accessed through the above four types of addresses, and some machines can also be accessed through 0.0.0.0. This type of address is not widely accepted, and more is used as a reserved address for matching all ips. The dns service that comes with each computer will resolve localhost to 127.0.0.1 and then point to the local machine, that is, the domain name corresponding to 127.0.0.1 is localhost.
If the computer is connected to the Internet, you can also access the local area through the ip of the network card, such as 192.168.0.1, what is its corresponding domain name? No need to check the dns cache, just open your computer business card and you can see it. For example, on a Windows computer, you can view the business card in [Control Panel/System and Security/System]:
(I'm not here to show memory)
The computer name is your host domain name, which can be resolved into your network card ip. Take my computer as an example. Just open an http service and you can directly visit http://desktop-oakgfsr/ in your browser.
How to go to https? Naturally, fake certificates cannot be used, but there is no need to spend money to find a CA to issue a real certificate. Wait, neither real nor fake certificates are needed? ? ? Misunderstanding, we use a real certificate, but only a self-signed certificate with openssl. For convenience, we don't need to do experiments with openssl. Just find an online ssl certificate generator on the Internet.
After entering the domain name as required, the generator will quickly create a certificate and private key for you:
desktop-oakgfsr.cert: self-signed certificate
desktop-oakgfsr.key: the private key of the certificate
Install a self-signed certificate
If you don't understand the principle of https very well, I recommend reading this article: "HTTPS and P=NP Problem Solving" , which chewed up the principle of https and sent it to your mouth. Next, let the operating system or browser trust the certificate: double-click to open the certificate, and click install.
Select [Trusted Root Certification Authority] for the certificate import location.
Open [Manage User Certificate] and you can see the newly installed certificate:
Of course, you can also choose to import the certificate here, the effect is the same. Finally, we use this certificate and the private key just now to open a local web server, monitor port 443, and the browser visits https://desktop-oakgfsr/, and it succeeds.
If you find that it does not take effect immediately on chrome, you may need to restart the browser or even log in to your Google account again. Since then, all the latest Web APIs can be used.
<end>