We are using a custom protocol handler to connect to an embedded device across firewalls, NAT etc. The solution is called Nabto.
This works great - a plug-in on the user's computer handles requests to all nabto:// URIs and serves HTML pages with information about the current connections etc.
Now, we would like to access Nabto functionality from a regular web page. This is difficult with browsers enforcing the Same-Origin policy (e.g. our http page cannot communicate with the nabto page).
So far, I am trying to solve this using easyXDM by having a "proxy page" served by the nabto plug-in. This page is then allowed to launch nabto:// requests and can communicate the results back to the http page using easyXDM.
However, same-origin requests fail in Internet Explorer - even when both pages reside in the nabto://self domain. I get this error: image
Is this an error in Internet Explorer? Any idea how to solve it?
Thanks a lot,
Martin
We had huge issues that sound similar to yours when developing the plugin. I must admit that we gave up getting clean Ajax support working through Nabto after spending a lot of time on it. In fact, the final thing that happened was opening a support case with Microsoft about it, the case bounced around and we never heard anything back.
There might be a chance though for a hack: In the meantime we realized that IE allows you to populate images through nabto:// urls on an http / https page. Maybe you can populate an image object through your query and extract the result from there?
On a side note: You are welcome to post in the support forums (forum.nabto.com) about such things. On the other hand, you help spread the word about the product in this way ;-)
Ulrik
Related
A while ago I created an application whereby clients connect to a server using WebRTC protocols.
The clients screen is made up of two halves. One half is linked to the server and receieves things like messages, and has the web page which has the WebRTC javascript in it. The other is an IFRAME. When the client connects to the server, the server sends the client a web address which is loaded in the IFRAME.
I know that some web pages cannot be loaded in an iframe, examples typically having password screens. Google forms does not appear to have this restriction, which is great.
So now imagine I launch a server and ask 20 people to connect to it. All 20 students connect to the server properly, I know because it comes up with all their details on my computer. Typically, from my testing, 15/20 will be fine. The other 5 will get a white screen. When I investigate in the console it is an XFRAMES ORIGIN problem, its saying the webpage being loaded will not allow itself to be loaded in an iframe. However everybody else (who are using the same browser [chrome], and some the same browser version) are fine.
Now I have one solution which works for some students, there is a setting in chrome which is called:
block third party cookies and site data
If this is enabled it doesn't work, if its not enabled it does work.
Now I have 4 students left who still just see a white screen whom I have no solution for. Chrome and Firefox both support the software but both produce the same issue.
The building setup is that students connect to the internet through a server. They must connect via this server as my nameserver is not local and indeed my website is not local either.
I dont think it is a coding issue as it only happens on a few select computers and everything else works just hunky dory. Thus I think it might be an issue with something else: firewall, security settings, config button etc. If anybody has any suggestions for what i can do to remedy this then I would be very grateful for your help.
I have tried to supply all info I believe to be relevant (hense the length) but anything I have missed please ask.
Thank you.
Alex
If the main site's URL is different than the iframe's URL, you'll get an xframes origin problem. This includes the protocol (http vs. https) and full domain (example.com vs www.example.com). In other words, if a user goes to example.com and the iframe uses www.example.com it could cause an xframes origin error. Or if they go to http://www.example.com and the iframe uses https://www.example.com you might get this error.
OK so for people who encounter this issue in the future I am going to create an update this post here. Basically it is for people who want an answer to the issue of iframes just displaying a whitepage.
With these three solutions I have eliminated all my issues, but as I come up with new ones I will post them here. Hopefully its useful to somebody :)
SOLUTION 1
If your iframe is aiming somewhere that requires the user to log in, it is unlikely to work. Password pages are rarely cross origin for obvious and good reasons. The solution is to ensure before they use your iframe page they log in fully to what they are doing, or provide an error message that gives them this information if it happens. See this post for details: Catch error if iframe src fails to load . Error :-"Refused to display 'http://www.google.co.in/' in a frame.."
Where I am we had dual login, so they sign into google and then into the organisation. Both these login areas will cause your page load to fail.
SOLUTION 2 (Chrome ONLY)
Some services react badly to QUIC mode, and some of my users have had issues due to this.
To fix:
1. chrome://flags
2. change QUIC mode to 'Disabled'
SOLUTION 3
If you are working via a proxy server that requires cookies, users may have issues if they have the 'Block third-party cookies and site data' button enabled. Disabling this had a positive effect on how well the iframes were working.
In chrome:
Settings
Search for cookies
Click 'content settings'
I am building a web application that uses voice recognition & text-to-speech that performs actions/displays a wide variety of data through an HTML page (built with JS (jQuery for AJAX)/HTML/CSS.) This web application is being hosted on HTTPS server that is not on my local network.
I have set up and configured some smart lights called "Philips HUE Lights" that are equipped with a RESTful API that can only be controlled through the local network (not visible outside of the local network.)
I am able to send commands to the device by visiting the CLIP debugger/API tool (local ip) "http:////debug/clip.html" that is included with their product. I am able to send HTTP commands to the "Philip HUE Bridge" which is the device that issues the commands to the lights. All of the commands work when I use their API tool (GET, "PUT, POST, DELETE) visiting the locally hosted url shown above.
However when I try using a jQuery AJAX request "GET"/"PUT" from my web application that is hosted on my HTTPS server, the command fails. I have tried setting the AJAX function header property with "Access-Control-Allow-Origin: *". I have also tried setting the "crossDomain" property to true in the AJAX function. I also have tried setting the "dataType" property to both "json" and "jsonp" and it still won't work.
I am visiting my HTTPS web application through a computer that is connected to the local network that the "HUE Bridge" is connected to. Given that I am using a computer on the same network, I thought this might work...
I have read a lot of other posts/information on the internet but can't seem to find a definitive answer. I wanted to ask some of you more seasoned people:
Is what I am trying accomplish even possible given the scenario I described above? Or will I have to achieve this in a different manner?
Any help/suggestions are much appreciated. Thanks.
You are running into "Mixed Content" security issues.
Basically when you are hosting a page on a secure URL (https) you cannot access unsecure (http) resources without getting a mixed content error.
This error is visible in the console of your browser (usually accessed by F12), when something is not working during webdevelopment always check the console for errors.
To hack around this you can temporarily disable the security and allow the unsecure request. For example Chrome shows a shield in the addressbar which you can click to temporarily disable the warning. Firefox shows a clickable warning overlay on the lock icon in the addressbar.
This might be a temporary workaround for development, but you cannot expect your users to disable security.
A solution should be to send a Content-Security-Policy header. Based on documentation from http://content-security-policy.com/ the following header should allow XMLHttpRequests to any resource:
Content-Security-Policy: connect-src *
However since I do not have enough control to modify the headers on the webserver where my files are hosted I could not test this.
Before using this method make sure you understand the security implications when you send this header.
I'm building an automation tool at work, and I've hit a bit of a snag... The task is to automate the laborious process of navigating a large web-based GUI which sends queries to a database based on the values entered in various fields. We do not have access to the database itself or the server on which the web-GUI is located. Furthermore, the protocol for the web-GUI is https. Is there any way to have javascript open the web-GUI in a new window and then act on it [clicking buttons, reading returned text strings etc.]? The implementation doesn't have to be javascript (autoIT would do the same job much more easily) but I am curious as to how the access denied errors might be overcome. I have read about certain workarounds, but none of them went so far as to actually attempt to interact with elements of the cross-domain document. I have also discovered easyXDM, but it doesn't solve the protocol discrepancy, and I'm not certain it would work for my situation anyway. Any input would be appreciated!
thanks,
CCJ
You are not going to be able to do cross domain because of the same origin policy.
Sounds like you should do something with greasemonkey or with selenium to automate it.
I've been playing with the visualization API aka dynamic charts and I've found that the example at http://code.google.com/apis/visualization/documentation/gallery/annotatedtimeline.html does not really work on localhost. That is, Error calling method on NPObject is thrown when a event is clicked (points A and B in the example aforementioned). I suppose that is a security issue on the server end (Google's flash base).
There's no API key, authentication or anything similar required - as far as I know. What am I missing?
Thanks
Update:
The very same example on jsFiddle: http://jsfiddle.net/gT5GB/ Localhost seems not to be the issue, it's the non-google domain I guess.
Since that jsFiddle code is hosted on a domain, the note at the very bottom of the documentation should not apply:
Because of Flash security settings,
this (and all Flash-based
visualizations) might not work
correctly when accessed from a file
location in the browser (e.g.,
file:///c:/webhost/myhost/myviz.html)
rather than from a web server URL
(e.g.,
http://www.myhost.com/myviz.html).
I had the same issue today and have solved it. I was not using localhost anywhere, I was hosted on a proper domain, and I too was receiving the NPObject error when clicking on the legends. I was also just using the example directly from http://code.google.com/apis/chart/interactive/docs/gallery/annotatedtimeline.html
The cause was that Google's example uses https://www.google.com/jsapi (note the HTTPS), whereas my site was over plain HTTP. I'm not that familiar with Flash, but I suspect it has similar rules for secure/non-secure as it does for crossdomain requests.
Changing Google's example to use http://www.google.com/jsapi solved the pr
Yes, this is a limitation related to security in Flash. It's covered here: Flash - HTTP requests won't work on localhost
So your best bet is to host this somewhere (it can be a server in the same machine).
I am posting this question on Super User as well. In my opinion this question overlaps the two...
I am creating a simple JavaScript wrapper for CouchDB's REST-ful interface, but I am stuck on same-origin policy issues.
So far I've been developing my code to work locally - and only as a proof of concept - on Mozilla FireFox. My server is running on localhost, port 5984.
To disable cross-origin policy in Mozilla FireFox you can use the PrivilegeManager, but it only gets me half-way in the sense that I can't do PUT requests against my server...
/*
* Including this in my JavaScript file only seems to disable cross-origin
* policy checks for POST and GET requests in Mozilla FireFox.
* PUT requests fail.
*/
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead UniversalBrowserWrite"
);
Is there any way that I can configure my server to hide it's location so I won't have to implement browser-specific work-arounds to avoid same-origin policy issues? If not: what browser work-arounds exist to disable same-origin policy completely?
Unfortunately, any browser workarounds to disable same-origin policies are likely to be treated as serious security bugs and fixed as soon as possible.
See if you can come up with a way to work within the same-origin policy without trying to bypass it.
Can you serve your example scripts on the target server? Could you build a reflection script that would load the target script on your server after a local script on the users computer uploaded whatever they modified?
There should be a good solution that doesn't involve bypassing the same-origin policy. Trying to hack your way around it is a good way to ensure that your code doesn't work properly in future browsers.
I strugled with that issue too, trying to run automated tests on a local html file connecting to a virtualized CouchDB server, here's my solution:
I created a small implementation (and open sourced it) of the simplest solution when you can't enable CORS on the server,
you need to upload a .js and an .html file to the target server, (you can use any security mechanism to restrict access to this file if you want). Or you can change some simple parameters on the html file to restrict by domain.
On your page you use the same script to create an invisible iframe where the hosted .html is loaded, and proxy certain methods (sort-of RPC) thru that iframe using window.postMessage(), by default jQuery ajax methods can be proxied without extra configuration.
All this with one line of js code :)
FrameProxy at GitHub
(fell free to use it and fork it!)