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 am working on my app and I have an issue with cookies. To be more specific - cookies are probably not send from an iPhone (chrome, safari).
Wierd part is that when I open my app on any other device (in production) everything works nice as I expect. Only on iPhone, cookies are not send with each request (I can see in the logs, that cookie object is null).
When I open my app on PC and inspect cookies in chrome dev tool, they are not there, but when I ran my app on dev server, everything works just fine and even cookies are in the dev tools.
Also, I am getting this warning in chrome, but i don't know if this has any association with my problem.
A cookie associated with a cross-site resource at domain.com was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.
Do you have any idea, why this is happening?
Thanks for your advices
I am creating a HTML 5 app that uses a .net Azure Mobile Service and coming across a weird issue when trying to login a user on Internet Explorer (and only IE): It brings up a Windows Security dialogue box with the message :
"The service (back-end url) is asking for your username and password.
The service reports that it is from Service"
Dismissing the dialogue box gives the error "Access is denied."
I've tried entering my application key for the password (as you would do when testing the api) but that did not work. I've set up CORS correctly as I can make calls that only require the application key and turned off intranet discovery. I even tried deploying to a azure website to see if was a local issue. No luck.
Chrome & firefox do not show the dialogue and does the callback as usual.
I had this same problem and used Fiddler to inspect the differences between IE and Chrome. Chrome was not presenting this credential pop-up for Azure Mobile Service credentials and IE was. It turns out it is a CORS (Cross Origin Resource Sharing) issue in IE. If you inspect Fiddler, IE will report a HTTP 401 Unauthorized response for a cross domain GET call to AMS.
The solution is to go into the Azure Portal to your Azure Mobile Service and go into the 'Configure' tab. Within here you can set up and add the valid CORS URLs. This does include any addresses that are valid to call your service. It could be public and might be *. If you have it restricted make sure you include any 'localhost' addresses as well that might call the service during local development using IE.
For more information please see the following:
Cross-origin resource sharing
I'm trying to write an app using Sencha Touch that ultimately targets iOS and Android. It's supposed to log into the corporate web server and then retrieve and parse some JSON data. It should be very simple. However I'm very new to both Sencha and Javascript, so I'm having a hard time doing this sort of client-side authentication. I can't even seem to make it authenticate from a web browser on my dev machine.
I used this link to help create my login page:
http://miamicoder.com/2012/adding-a-login-screen-to-a-sencha-touch-application/
But when I attempt to log in I seem to get the following error message and a null object:
XMLHttpRequest cannot load https://www.server.com/index.html?=_dc1234567890123
Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin.
Does anyone have any advice or good resources on getting this app to log in? Any help would be greatly appreciated!
Steve, the "is not allowed" error is returned because your login request violates the browser's same-origin policy (essentially it states that all XhrHttpRequests must go to the same domain the page was initially loaded from).
Some browsers offer ways of disabling this error temporarily (which might be fine for short-term development purposes), but for the long-term you'll either need to host your application in the same domain as your backend server, or look into using CORS or JSONP for your requests.
Your AJAX request violates the Same-Origin-Policy. That's why you are getting the error message. If you are using chrome for debugging u can disable the cross-domain Javascript security by doing the following :
For Windows:
1) Create a shortcut to Chrome on your desktop. Right-click on the shortcut and choose Properties, then switch to “Shortcut” tab.
2) In the “Target” field, append the following: –args –disable-web-security
For Mac, Open a terminal window and run this from command-line:
open ~/Applications/Google\ Chrome.app/ –args –disable-web-security
For Ubuntu, Open a terminal window and run this form command line:
open /usr/bin/ and execute ./google-chrome --disable-web-security
There is extension for chrome that does the work:
Allow-Control-Allow-Origin.
If you want to active it when the browser started, you have to press on the icon.
I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.
It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.
I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.
Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,
Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.
The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...
I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)
I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.
In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.