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.
Related
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 can't intercept requests made by Chrome version 73.0.3683.86 to my localhost site.
Local host site is running on IIS on http://127.0.0.3:80
Burp proxy lister is default one on 127.0.0.1:8080
Interception rules are default one as well
In my LAN settings, "Bypass proxy server for local addresses" is not enabled
When Interception is turned ON and I reload page in Chrome browser, no request is "caught" by Burp, my local site loads and only the external requests are intercepted, such as loading external scripts from CDN.
Also under "Proxy" > "HTTP History" there is only request to external sites, and all requests to http://127.0.0.3:80 are not recorded.
When I reload same page by Internet Explorer 11, initial GET request is intercepted by Burp, as expected. Also "Proxy" > "HTTP History" shows all the requests to local site http://127.0.0.3:80
What is the problem with the Chrome? Thanks!
Found the solution late yesterday. I am using the Chrome extension ProxySwitchy, but it doesn't matter if you use that or the system proxy configuration. The solution works the same way.
You can solve this problem by adding an entry in /etc/hosts file like below
127.0.0.1 localhost
127.0.0.1 somehostname
Now burp will intercept request from somehostname
Which version of Chrome are you using?
Have you tried using the FoxyProxy Chrome extension?
As a workaround, you could modify the hosts file on your machine.
I experienced the same issue when I upgraded from Opera 58.0 to 60.0. I think that this is Chrome related, because I've also experienced it in all other Chrome browsers. Opera 58 utilizes Chrome 71.0.3578.98. Opera 60 utilizes version Chrome 73.0.3683.103. Something was definitely updated in Chrome between these versions to cause this problem to happen.
You have to subtract the implicit bypass rules defined in Chrome (https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Implicit-bypass-rules)
Requests to certain hosts will not be sent through a proxy, and will
instead be sent directly.
We call these the implicit bypass rules. The implicit bypass rules
match URLs whose host portion is either a localhost name or a
link-local IP literal. Essentially it matches:
localhost
*.localhost [::1]
127.0.0.1/8
169.254/16
[FE80::]/10
https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Bypass-rule_Subtract-implicit-rules
Whereas regular bypass rules instruct the browser about URLs that
should not use the proxy, Subtract Implicit Rules has the opposite
effect and tells the browser to instead use the proxy.
In order to be able to proxy through the loopback interface, you have to add the entry
<-loopback>
in the list of hosts for which you don't want to a proxy. It is a bit confusing, indeed.
Make sure you haven't enabled socks proxy option, it happened with me too and i found the solution when i disabled the socks proxy option, just make sure it's disabled!
Example:
It helped me
I turned on this settings
In my particular network environment the Google chrome executable can access via an authenticated outgoing proxy server external web sites. Other executables however (when pointing to that outgoing proxy) are not able to do so.
I now have the idea to use Chrome itself as a local proxy for other executables like git or pip. - Is this possible, say, with a Chrome extension or with a tool that uses Chrome in a headless mode to connect to the Internet?
To clarify, I am not asking how to configure the proxy settings inside Chrome - I have successfully done this. I am asking how I can set up Chrome to receive HTTP(S) requests from other local programs and pass the requests on as an intermediate proxy (to the outgoing proxy specified in Chrome's settings).
On its own, no: Chrome will not open a port that other software can connect to. Even WebRTC requires an intermediate server to begin a peer to peer connection between browsers.
However Chrome supports Native Messaging, which means it will execute a specific native application that already exists on the system.
With this set up you can have:
a native application that accepts incoming connections and forwards data to the extension.
the extension listens to messages from the application and sends them via Chrome elsewhere on the internet.
Using: Chrome 67.0.3396.99
Our webserver implements X.509 client authentication. The certificates are offered through the PKCS#11 interface; we connect a smartcard (in this case: Yubikey 4), the browser prompts for the certificate selection and PIN.
We disconnected the smartcard and visited the authenticated domain (say, localhost:8000) to observe the behavior of the webserver (in a local development environment).
The webserver correctly refused to serve the request.
However, Chrome now does never send anymore the certificates while visiting localhost:8000, even if the smartcard is connected.
The following did not resolve the problem:
Clearing all site data through the developer console;
Resettting site preferences to their defaults (through chrome://settings/content/siteDetails?);
Rebuilding the webserver.
Any pointer where I can clear this state from Chrome would be greatly appreciated. As a temporary fix, we run the server at a different port but this is not an option on the long term. As this scenario is very plausible to also happen in production.
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