I am developing an application that uses WebRTC and I want Chrome to use the system camera. From what I understand, the use of the camera is allowed (in the latest versions of Chrome) only from "secure locations" (https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins), like localhost and 127.0.0.1.
I want to test it locally and connect to the server both from a client that resides on the same pc as the server, and from a client from another pc. In particular, the client that connects from another pc needs to connect to the server using its IP address (I am developing/testing it in an Intranet), but the client cannot use the camera because it is not calling localhost.
Is there a way to disable this constraint, so that I am able to test it in an Intranet?
If not, are there any alternatives?
try the unsafely-treat-insecure-origin-as-secure flag in Chrome:
http://peter.sh/experiments/chromium-command-line-switches/#unsafely-treat-insecure-origin-as-secure
Related
I have an R script that uses Plotly Dash to create a web page. I am running the script on a VM instance in GCP which is a Ubuntu server without GUI. When the script is executed, it says,
start 127.0.0.1:8050
My question is how to access this web page on a browser from anywhere. Since the VM doesnt have a gui/browser I cannot even test my web page..
Anyone could explain what I am missing here or any way to deploy my web page and access from anywhere?
I am unsure how your application works, but that ending line shows that the server is running on localhost and on which port is it serving. So you may want to access from an external browser with the instance's ip address: like http:// xx.xxx.xx.xx:8050 and let's see if it works. Otherwise you may need to set up a Remote Desktop Setup through Chrome to enable a GUI interface on the VM.
Also remember to make sure that traffic is allowed on that port 8050 checking /creating the firewall rules
I encountered the same problem. You need to change the IP address on which the dash server is running to the internal IP address of your gcp VM instance. It usually starts with 10.xxx.x.x. You can find this internal address in the 'IP address' tab in the VPC networks section on the google cloud console. So do this:
app.run_server(host='10.xxx.x.x', port='8050')
Open a browser and browse to http://externalip:8050. Make sure you have your firewall rules set up correctly.
You should now be able to see the dash app.
Background: I have a web app that is accessed via Chrome on a Windows 10 machine.
I also have a native Win10 application installed on the device. The web app sends data to the Win10 application via a local web service running on the machine in IISExpress.
To allow for HTTPS communication on port 44300, I've created a self-signed certificate via PowerShell:
New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(60)
And then imported it to 'Local Computer\Trusted Root Certificates\Certificates'
From within the web app I send a command to the win10 app that looks something like this:
https://localhost:44300/CMTService.svc/JumpToAssignment?Param=Key=418584577
The win10 app is polling for these requests and picks up the message.
Issue:
Different versions of Chrome behave differently with the acceptance of the self-signed certificate. For instance versions 62, 64 and 75 all accept the certificate and allow for communication with the web service. But other versions of Chrome like 76 and 78 block communication. The Security tab in the Chrome DevTools shows https://localhost:44300 as "Unknown / cancelled" and my requests fail with ERR_SSL_CLIENT_AUTH_CERT_NEEDED. Whereas in working versions of Chrome my URL shows under "Secure origins". The only thing that I change is the Chrome version to get these different results.
I've tried enabling the Chrome setting to allow for invalid certs for localhost (chrome://flags/#allow-insecure-localhost). This temporarily works, but then after closing and reopening chrome, my requests start failing again with the same error code.
If I take one of my failing URLs and paste it into a new Chrome tab, suddenly communication with my native app in my web app resumes as normal. But it only works for that session - when I close and reopen Chrome my communication is broken again.
Question:
How do I allow for communication between my Chrome v78 web app and my local native app?
ERR_SSL_CLIENT_AUTH_CERT_NEEDED means the server is asking the browser for a certificate for client authentication.
You've described how you setup server authentication, but not described how you setup client authentication.
Likely you have enabled certificates for client authentication, but have not configured the web app to send the correct client certificate or have not configured the native app to accept the correct client certificate. That's a very open ended topic to be prescriptive without knowing more about your development efforts, but you can confirm if client authentication is enabled by inspecting a packet capture. One description of the handshake is here : https://blogs.technet.microsoft.com/nettracer/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication/.
Just an update: I implemented a javascript workaround to get around my communication issues. When first loading the web app, I simply send my first communication to IIS (destined for Win10 native app) in a separate chrome browser tab. For whatever reason this allows for successful acceptance of the certificate and kick starts the communication with IIS. This is my code to send the command in a new tab and then close it:
var inst = window.open(launchWinAppURL);
if (inst != null) {
window.setTimeout(function() {
inst.close();
}, 1000);
}
This is not the most elegant solution, but it seems to work on all chrome versions, so i'm satisfied.
Is the web app only communicating with the one win10 machine? Have you installed the self-signed cert directly to the machine? I would try installing it directly to the machine and see if the later instances of chrome allow communication.
I am hosting my page inside the sdcard of arduino, I have implemented web speech api feature in that, however when I test my site using 127.0.0.1/project-X , everything works perfect, but when I use 192.168.1.4(which is same machine) or 192.168.1.10 (which is other laptop having WAMP) Chrome does not allow the microphone? I have also tried to start Chrome using different flags found on Google but none of them worked. What to do? I just want Chrome to allow using microphone from local ip also!
Chrome now allows Microphone access over secured Http only. You can very easily create your own signed SSL certificate and use that to host your page via Https.In tomcat server.xml you just have to un-comment the ssl connector and point to the location of your certificate.
I am developing a webpage that uses camera. When I test in Chrome in my local network, camera doesn't work and I get warning in the console:
getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See link for more details.
In the link provided there is an instruction to set some flags in Chrome. So I tried. My command looks like this:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="192.168.0.15" --user-data-dir=c:\chrome-dev-profile
But when I run Chrome I get this message:
You are using an unsupported command-line flag: --unsafely-treat-insecure-origin-as-secure. Stability and security will suffer.
What am I doing wrong?
Is there another way I can test in local network without setting up https server? I need this just for development.
Luka,
I've run into this bug just yesterday. I have not found out how to get Chrome to honor that flag on the command line yet. But I did find a workaround that works for my case.
I'm running my web services on a Linux machine that is running an ssh server. I'm testing on windows with chrome, and used putty to connect to the linux box from windows and then created a "local port forward" to make my remote linux box's ipaddress:port appear on localhost:port on windows. Depending on your platform this workaround may work for you. This approach isn't too cumbersome if you only have a few ports to forward.
In my particular case my setting for putty looked like
L8080 localhost:8080
To see more about port forwarding and ssh see: https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
I need to convert a web page requiring viewing a X window from using the VncViewer applet to some HTML5 based VNC client. The worry is NSAPI will get desupported in the near future on browsers (mainly Chrome) that disables applet functions.
I looked at noVNC and websockify and got it to work. But, here is my problem: We still have some client on IE8 that does not support Canvas. For those clients which has Java enabled and won't be changing to a higher version of IE or Chrome, we still want them to keep running the applet version. By running websockify in the wrap mode, it seems I can no longer directly connect to the VNC server (not through websockify) to keep those applet clients functional.
e.g. My command to run websockify is:
run 5903 --wrap-mode=ignore -- vncserver -geometry 1024x768 :3
After this, I tried to use the regular VNCViewer client to connect to port 5903, and it's rejected. Only the websockified page can view the VNC window. If I change the 5903 to 5902, then I can use the regular VNCViewer client to view window at 5903, however the websockified page can't view it at 5902.
Is there a hope to keep concurrent connection to my VNC server available (websockify and regular connections)?
Thank!
I would recommend starting your VNC server normally (not using websockify wrap mode). Then run websockify normally to target the VNC port. The Java client should continue to target the regular VNC port. The noVNC client should connect to the websockify listen port (which will then connect to the VNC server target).
The problem with wrap mode is that the original port is "hidden" (moved to a random high port and accessible to localhost only) and only the websocket port is exposed. But you still need the regular VNC port to be accessible for the Java client.