I have a form in my laravel webapp where the user needs to add a profile picture through webcam. While developing in localhost(secure origin), it was working fine but now when i am trying to access it using my IP address, it doesn't seem to work.
I used "navigator.mediaDevices.getUserMedia" for accessing webcam while developing my project but now when the website is made live(or testing through my IP), chrome says that "getUserMedia() no longer works on insecure origins". I also tried Webcam.js but same came across the same error.
navigator.mediaDevices.getUserMedia(constraints).
then(handleSuccess).catch(handleError);
Error output in console:
[Deprecation] 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 https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins for more details.
Starting with Chrome 47, getUserMedia() requests are only allowed from secure origins: HTTPS or localhost.
did you check this page? I think you're using HTTP. I'd like to switch to HTTPS and test it.
https://developers.google.com/web/updates/2015/10/chrome-47-webrtc?hl=en
As you can see from the doc, chrome requires a secure context for using it:
So you must switch to https for testing it in chrome
Related
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'm using react-webcam to capture a selfie for an application. On localhost, react-webcam works perfectly whereas on HTTP hosted web server camera access is being denied by default on the Chrome. Is there any workaround for webcam access or any other npm plugin which can serve the purpose here.
NOTE: HTTPS supported sites are allowed to access both the Camera & Microphone. Here, I'm left with only HTTP choice.
The react-webcam uses the getUserMedia API which specification states:
When on an insecure origin [mixed-content], User Agents are encouraged to warn about usage of navigator.mediaDevices.getUserMedia, navigator.getUserMedia, and any prefixed variants in their developer tools, error logs, etc. It is explicitly permitted for User Agents to remove these APIs entirely when on an insecure origin, as long as they remove all of them at once (e.g., they should not leave just the prefixed version available on insecure origins).
Chrome, starting from version 47 implements this security policy (Source):
Starting with Chrome 47, getUserMedia() requests are only allowed from secure origins: HTTPS or localhost.
So you can't access Microphone or Camera without a secure connection.
If you are using this for a development environment and want to test it on your phone you can do the following:
Go to: chrome://flags/#unsafely-treat-insecure-origin-as-secure
Enable `Insecure origins treated as secure`
Add the addresses for which you want to ignore this policy
Restart chrome
I am using Google's WebSpeech API found on this site:
https://developers.google.com/web/updates/2013/01/Voice-Driven-Web-Apps-Introduction-to-the-Web-Speech-API
With Python's http.server on my Windows machine,
it works without any problem:
I upload exactly same files, same API but it does not work in my CentOS remote server throwing a 'not-allowed' error for the microphone permission:
I thought that problem could be http server related. So I tried with Apache Httpd, Python http.server and Nginx. None of them worked.
Any idea about what's blocking the microphone?
Thanks!
I couldn't find documentation backing this up, but from my own experience I can confirm that only after installing an SSL certificate on a website, chrome stopped blocking it from requesting microphone access.
I experienced not-allowed also - trying to access mic from Chrome inside cross-origin iframe. Resolved by adding allow="microphone;" to the iframe:
<iframe src="mysrc" allow="microphone;"></iframe>
Note: Also required using HTTPS for parent page & iframe page
Reference: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes
I've encountered the same issue (throws not-allowed), but I was using HTTPS.
In my case, it turned out that you can't obtain speech or enable microphone access from an iframe. The same code works normally when not shown in an iframe.
I'm pretty aware of this warning that being shown when attempting to ask permission of using the Mic on non HTTPS origins using chrome.
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 https://goo.gl/rStTGz for more details.
So my question is there a way to test, demo, sandbox, etc this feature of HTML5 in chrome without having to buy/install/configure or create a ssl certificate ?
I read something on SO about localhost being treated as a secure origin over http (just tested this with chrome 48 and it's not working).
Is there a way to use IP's (e.g : 192.168.1.2) instead of example.com when using this chrome flag ?
--unsafely-treat-insecure-origin-as-secure="example.com"
I have an addon for Firefox which modifies a page at http://target.com with data from http://data.com. It does this by making an XMLHttpRequest() in the addon javascript and modifying the webpage accordingly. Neither the target nor the source servers are under my control.
This all worked fine until the target.com website changed to using https. As I was loading data from an http: address I got the following error:
Blocked loading mixed active content
Fortunately data.com also supports https, so I changed the data lookup address to https://data.com, and then I got
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://data.com
I read here that I could add the following to my package.json
"permissions": {
"cross-domain-content": ["https://data.com"]
}
And now I don't get any errors, but the Developer Tools Network page doesn't show any connections being made.
Have I hit a dead end? I understand that CORS requires server support but I assumed that as it worked prior to the target server moving to https it would still work now.
Cheers
Rich
That is one of the issues with using libraries (and not Firefox API)
Try using the native Firefox API eg: Connecting to Remote Content
Native Firefox API runs in the browser scope so there is no CORS to consider.