Is there any way to access the Microphone and Camera using chrome when the website is http?
I tried enabling "Insecure origins treated as secure" flag, however when the browser is closed and opened again, the domain used in this flag disappears and I have to retype and re-enable it again.
I also tried starting chrome with "--unsafely-treat-insecure-origin-as-secure=http://example.com" argument, however when this was used a message appears on Chrome saying
You are using an unsupported command line
flag:--unsafely-treat-insecure-origin-as-secure=http://example.com.
Stability and Security will suffer
I don't want the message to appear, so I couldn't use this technique as well.
Is there any other way to access the Microphone and Camera without getting any warnings? (I am accessing the device using WebRTC).
This worked for me. Although it's for Testing purpose only.
To ignore Chrome’s secure origin policy, follow these steps.
Navigate to chrome://flags/#unsafely-treat-insecure-origin-as-secure in Chrome.
Find and enable the Insecure origins treated as secure section (see below).
Add any addresses you want to ignore the secure origin policy for. Remember to include the port number too (if required).
Save and restart Chrome.
Remember this is for dev purposes only. The live working app will need to be hosted on https for users to be able to use their microphone or camera.
"unsafely-treat-insecure-origin-as-secure" flag is not working on Chrome
You are not allowed to run webrtc on http after Chrome 47+ version, but you can do some hack for this with some changes in ngnix.cong file, as
//Make necessary changes
server {
listen 8080;
server_name localhost;
location / {
proxy_pass http://your.dev.box.ip:8080;
}
}
Reference : https://webrtchacks.com/chrome-secure-origin-https/
Update: this flag trick from Nafees Ahmad works for Chrome 89, also Chrome Android (I use huawei Mate 20 pro). It helps the website on Chrom access camera or NFC function.
Related
What is the purpose and the code content of the "Proxy Script" that Chrome attempts to load every time a new page is loaded?
An easy way to trigger this message is to turn on and off Airplane mode:
This happens when your computer's network settings have a HTTP proxy configured. The proxy auto-config (PAC) script file is specified in those settings; Chrome then downloads it and runs it to determine whether and how each request will be proxied. The script is provided by your proxy, not Chrome.
If you are not intentionally using proxies, you should remove the proxy configuration as it might be either unnecessary or malicious. But if this is a machine owned by your employer, it is probably intentional.
I'm not sure if this work the same way on all OSes, but for me on macOS, there's a link from Chrome's settings to the OS network settings:
The reason the message pops up when you enter/exit airplane mode is probably because that counts as a change of network configuration (between "no internet (and no proxy)" to "yes internet and also proxy"), and it's making sure it has the latest PAC script.
If you want to find out what the script contains, copy the PAC URL out of your network settings and download it separately; then you can read the code (which is JavaScript).
I am currently experiencing an error everytime I use my Microsoft Edge. Whenever I try to go to a site, I always end up with this error. The weird thing is, this issue only happens on certain websites (such as Facebook and Yahoo currently) and sometimes with Google. It likes to disconnect me often and I really don't want to have to deal with this issue anymore.
My internet works fine as my laptop (which I'm currently on) and phone can connect to it without issue. I don't know why it doesn't work on my desktop especially since its internet is Ethernet.
I tested this on other browsers to see if it was only on Edge but it turns out that chrome and firefox experience the same issue with different sites as well. For all three, I haven't been able to go on Facebook and Yahoo, and sometimes Google.
I know the problem is from my end because clearly, the sites are up. Is there any way to solve this or has anyone else found a solution to this?
I'm running Windows 10.
I've tried the following:
ipconfig / flush
ipconfig / reset
ipconfig / release
ipconfig / renew
clearing caches and browsing history
a full scan for malware using malwarebytes and windows defender, already removed/quarantined all threats, did this multiple times to ensure there were none left
reinstallation of chrome and firefox and a reset of edge
ipv4 - changing preferred and alternate dns address to 8.8.8.8 and 8.8.8.4 respectively
checked to see if a proxy was up, no proxy
If I were to do a factory reset, would this solve the issue?
To narrow it down a bit, can you confirm that you only get this when navigating to the sites listed and they're using SSL / HTTPS? Some will auto re-direct to HTTPS if you go to their non-SSL equivalent, but it's worth trying this on sites like Google which do support both.
If this does help narrow down the behaviour, then I've seen this behaviour once before, but this was behind a corporate proxy which didn't support SSL SPDY.
You can try disabling SPDY support, but there is likely to be an underlying issue (perhaps anti-virus acting as a proxy?).
To test disabling SPDY:
Internet Explorer 11
In the browser, select Tools > Internet Options > Advanced > HTTP
Settings and clear the Use SPDY/3 option.
Firefox
In the browser, enter about:config in the address bar and press
Enter. Confirm the security warning. Type
network.http.spdy.enabled in the Search field. For all the entries, set the Value to false.
Chrome
Use a switch to disable SPDY for Chrome. Edit the shortcut for Chrome
and add the following switch at the end of the Target path:
--use-spdy=off
For example, if Chrome's default shortcut link is pointing to
"C:\Program Files\Google\Chrome\Application\chrome.exe", change it to
"C:\Program Files\Google\Chrome\Application\chrome.exe" –use-spdy=off.
Source:-
http://bluecoat.force.com/knowledgebase/articles/Solution/HowtodisableSPDYprotocolsupportinbrowsers
I had a caller who was getting the "can't load page" error in Chrome only when logging into the AMEX site. Every other browser worked. The fix was to disable some weird experimental Chrome setting that is on by default. Go to chrome://flags, search for "experimental quic protocol" and "Disable" it.
Source
Click on start/control pane/IE options/Privacy Tab/Sites
Look at list of sites to see if any Google sites are blocked.
I developed a chrome extension which communicates with IP phones.
The communication is done in a event page which is sending POST requests via the XMLHttpRequest object.
Because the hostname or IP address of the phone is configured in the options page I added optional_permissions to the manifest file and request them from the user after saving the options with chrome.permissions.request.
Cross-Origin XHR works now without any problems until I restart chrome...
After restarting chrome it seems like the requested permission is lost and I get the typical
is not allowed by Access-Control-Allow-Origin error.
When I click on the extensions permissions I can also see that my requested permission is no longer listed.
Because the chrome.permissions.request is only working for a user gesture I can't request it during the load of my extension or on the fly. If I request the permission again in my options page I don't get asked again whether I want to allow it or not put the permission is granted and everything works again as usual.
Is there a way to get this permission granted persistent after requesting it? I only want the extension to have access to the endpoints it needs.
Thank you very much.
For me the following reported issue answered my question:
Issue 158004: chrome.permissions.request support for user-supplied URL.
To make it clear: It is not possible to request a subset of the permissions defined in optional_permissions. If you define http://*/* then you need to request exactly this string! A subset like http://example.org/* wont work!
Here is a quote from a comment in the issue description which makes that clear:
"There's no wildcard handling, just plain string comparison between the URLPatterns"
The Issue has been fixed in Revision 182287
The only thing left is to cross your fingers that this fix gets included in a upcomming chrome release soon. We'll have to use the bloody Access your data on all websites permission in the meanwhile.
I have an existing site that works fine over http and https (SSL). The SSL certificate is valid and can be confirmed by inspecting in the browser.
I am starting to use a manifest file to enable the HTML5 application cache on my website. This is useful for making the page load faster, and eventually for offline capabilities. This is working great when using a regular http connection. The problems happens when accessing the site over https (SSL). When I do this, I can access my website's content just fine, and the URL says "https" however I see the following behavior:
Safari: It displays the lock icon, but when I click the lock icon to inspect the certificate, it says that the certificate is invalid.
Firefox: Does not display the colored address bar indicating encryption, and when inspecting the certificate, it says that there is no certificate.
Chrome and Opera: Correctly displays the secure nature of the URL, and when clicking the lock icon it displays the SSL certificate information. Yes!
I understand that using the application cache causes resources to be served locally from the browser, and as such there is no encryption happening, however customers don't necessarily know that there is an application cache happening in the background, and they are expecting to see a valid SSL certificate and indications that the connection is secure. Safari and Firefox appear to be doing this incorrectly, unless I am missing something. That is my question. Does anyone know how to get Safari and Firefox to display the SSL certificate for pages served from the application cache? Is there something special that you need to do, or is it a Safari and Firefox bug?
I believe someone has discussed this with me before. Please let me know if this helps.
Change all of your script and css references from
http:// or https:// to //.
If you haven't any then it is moot, but if you do, please let me know if that has an effect.
I believe this may be related to not being able to verify the references from a cached page.
Based on the history of vulnerabilities, I'd guess this may have been overlooked for the sake of fixing more critical issues. That said, I think this should be reported to both vendors now that some of the glaring vulnerabilities have been patched. Have you tested this with the latest releases of Firefox and Safari?
Did you serve the application manifest over SSL?
I want our app to show the online help page (so it's always up to date) or even a local page. However, it's likely to be blocked by the Firewall (Zone Alarm).
BTW, I tested this with Zone Alarm. It blocked access to a local .html file as well as to an .asp file on the internet. (I.e., tried to display a page in Internet Explorer and got the Zone Alarm dialog asking if I wanted to give permission to display
Is there a way around this?
Perhaps displaying the web page in the Web Browser Control?
It's actually very unlikely that web traffic is blocked at the firewall (unless you mean the file type is blocked?). What you may need to do in such a setting, however, is use the same proxy that IE uses, because direct traffic may be blocked.
The simplest way to do that is to use a high level windows API or IE itself, and HTTP download the latest helpfile if there is a new one - these mechanisms should know about any proxy.
Of course, your users may not be using IE, even if most are. So you might need to allow the user to specify the proxy, or be able to auto configure the proxy in the same way that the browser does it.
edit: I see you mean zonealarm is part of the problem. yes, that is tricky as you will have to either get your application 'blessed' centrally by whoever manages zonealarm in the customer organisation, or (if there is no central management) then the user will have to allow the app to communicate. Perhaps you should bite the bullet and have the online help simply be a website, and spawn the preferred browser via 'executing' the URL as suggested in another answer.
If the web browser isn't blocked the firewall then they probably open port 8080 for any app and thus your app shouldn't be blocked.
If the firewall only allowed port 8080 to IE; you would have to punch a hole in the firewall to use a new browser like firefox or chrome.
To open a web page using the user's preferred browser (with appropriate proxy and authentication settings), use something like ShellExecute with the URL of the document to load. Something like this would do it (where page is the URL to load):
HINSTANCE r = ShellExecute(NULL, "open", page, NULL, NULL, SW_SHOWNORMAL);