On the website http://imaginaryman-test.blogspot.com/ the typewriter is inside of an IFAME . Everything works correctly on all browsers when you go to the site directly http://castedspell.com/mark/ but when viewing the version embeded in an IFRAME it does not work on IE and throws errors in Chrome.
Unsafe JavaScript attempt to access frame with URL http://imaginaryman-test.blogspot.com/ from frame with URL http://castedspell.com/mark/. Domains, protocols and ports must match.
This is the source code for the embedded IFRAME
https://github.com/totheleftpanda/typeWrite/tree/master/mark
I understand that this is a security problem but I don`t know how to fix it and can not find any material that would help me solve the issue.
The easiest method is to set a PHP (or any server language) proxy that just gets the content of the page from the other domain and outputs it. The only real drawback is that the cookies of the client for the remote domain aren't sent.
Take a look at http://benalman.com/projects/jquery-postmessage-plugin/. This is a jquery plugin that sends message between the two frames. The two frames do not need to be on the same domain. But you do need to access both pages to be able modify them. I also wrote a post here that answers communication between iframes. How to capture clicks from iframe on another domain?
Your only chance is something like easyXDM. (or do it manually using the hash, but would prefer easyXDM)
See the SO answer: Cross-domain hash change communication
eg. if you wanna call a method:
http://easyxdm.net/wp/2010/03/17/remote-procedure-calls-rpc/
EDIT:
If I try your demo in firefox I don't get the "Unsafe JavaScript attempt to access" error at all. But in Chrome it's thrown many times.
You have so much other code in your example that I'm not even sure that your code causes the problem. You should do a very limited/basic test to see if your flash-communication works, without all those other javascripts.
I have had similar issues with this before. Basically if you have an iframe that contains a page from a domain that differs from the main page's domain, javascript will not be able to cross the boundaries between them. Javascript within the iframe will be able to talk within the iframe, javascript in the main page will be able to talk within the main page, but they will not be able to talk to each other.
This is a security issue that aims to stop cross-site scripting attacks. There are a number of hacks that you can put in place to get around this problem but they are all (or at least the ones I know of) rather hairy.
Here are some questions that you should answer before trying to go further:
1) What exactly are you trying to do between the pages using javascript?
2) Do you have access to the source of both pages?
It may be waaay simpler than the above answers. It looks like this function:
function playSound(){
swf.playSound();
}
Is written in the DOM timeline before swf is actually assigned to the swfObject in the function below it.
I would recommend moving that function down further and then retest.
Related
I'm designing some "add-on" to certain websites, which should be embedded in them as an iframe. Inside this iframe there is a clickable button aimed at changing the iframe's position within the parent website.
Since things are done in coordination with the parent website, I am able to add some code there as well. However it seems I am not able to do neither of the following (one of them should suffice):
From the iframe, access data within the parent.document, in order to move the iframe to the desired position.
From the parent website, access data within the iframe, in order to check when the button is clicked.
Both typically produce an error: "Blocked a frame with origin XXX from accessing a frame with origin YYY. Protocols, domains, and ports must match".
Any advice (preferably with code sample) is appreciated.
After doing lots of searching around, I came across this:
http://www.codeproject.com/Tips/585663/Communication-with-Cross-Domain-IFrame-A-Cross-Bro
I actually tested the method (using my own short piece of code) and it seemed to work on Chrome, Firefox and IE. Now I'm gonna try the "real" implementation...
From what I understand based on the information you've provided in your question, cross domain scripting is not possible. What you would need to do is provide a script that the parent-level website can paste into their template/html and run from their domain, similar to how Google does with their analytics system.
As an alternative, try turning your iframe content instead, into a div loaded with the response from a service call made from the parent domain to the iframe domain. You would most likely need to create an API that a requesting site can use. Simply call that URI with whatever parameters you would use when referencing the page you wanted to load in the iframe, and have the script that you run on the parent website handle all the DOM alterations you want to achieve.
Certain websites like Twitter, Flickr, etc avoid being stuck within an iframe. Is there any way to stop this from happening? I just need to see the public data so I am open to disabling Javascript, etc. How do I disable Javascript running on the iframe? Is this possible?
You can't disable JavaScript on iFrames or any other resources AFAIK.
The only way to reliably do this is to load the sites through a proxy PHP or other server-side script, filter out any JavaScript (which will break many sites), and fix all relative references to images and other media - a task that would take an insane amount of time to complete if you want the sites to actually work.
If you just need some data from the sites, proxying might work. Seeing as the Same Origin Policy would prevent you getting anything from an IFRAME from a different domain anyway, it is also the only way to access content on those sites using JavaScript.
In IE only, there is the <iframe security="restricted"> attribute. This disables JavaScript in the targeted document, which would break a JS frame-escape script — along with all other interaction that's script-dependent.
However, apart from the browser compatibility issue, it's very rude to frame a site that doesn't want to be framed, and it will work less and less anyway as more sites deploy X-Frame-Options.
I'm not sure what you mean by “need to see the public data”... as Pekka said, you won't be able to ‘see’ into an iframe's DOM from outside it, as that would be a security problem.
I apologize if this has been asked before. I searched but did not find anything. It is a well-known limitation of AJAX requests (such as jQuery $.get) that they have to be within the same domain for security reasons. And it is a well-known workaround for this problem to use iframes to pull down some arbitrary HTML from another website and then you can inspect the contents of this HTML using javascript which communicates between the iframe and the parent page.
However, this doesn't work on the iPhone. In some tests I have found that iframes in the Safari iPhone browser only show content if it is content from the same site. Otherwise, they show a blank content area.
Is there any way around this? Are there other alternatives to using iframes that would allow me to pull the HTML from a different domain's page into javascript on my page?
Edit:
One answer mentioned JSONP. This doesn't help me because from what I understand JSONP requires support on the server I'm requesting data from, which isn't the case.
That same answer mentioned creating a proxy script on my server and loading data through there. Unfortunately this also doesn't work in my case. The site I'm trying to request data from requires user login. And I don't want my server to have to know the user's credentials. I was hoping to use something client-side so that my app wouldn't have to know the user's credentials at the other site.
I'm prepared to accept that there is no way to accomplish what I want to do on the iPhone. I just wanted to confirm it.
You generally can NOT inspect the contents of an iframe from another domain via JavaScript. The most common answers are to use JSONP or have your original server host a proxy script to retrieve the inner contents for you.
Given your revisions, without modification or support from the secondary site, you are definitely not going to be able to do what you want via the iPhone's browser.
"In some tests I have found that iframes in the Safari iPhone browser only show content if it is content from the same site"
I found the same thing. Is this documented somewhere? Is there a workaround? This sounds like broken web standards to me, and I am wondering if there is a solution.
I'm just looking for clarification on this.
Say I have a small web form, a 'widget' if you will, that gets data, does some client side verification on it or other AJAX-y nonsense, and on clicking a button would direct to another page.
If I wanted this to be an 'embeddable' component, so other people could stick this on their sites, am I limited to basically encapsulating it within an iframe?
And are there any limitations on what I can and can't do in that iframe?
For example, the button that would take you to another page - this would load the content in the iframe? So it would need to exist outwith the iframe?
And finally, if the button the user clicked were to take them to an https page to verify credit-card details, are there any specific security no-nos that would stop this happening?
EDIT: For an example of what I'm on about, think about embedding either googlemaps or multimap on a page.
EDIT EDIT: Okay, I think I get it.
There are Two ways.
One - embed in an IFrame, but this is limited.
Two - create a Javascript API, and ask the consumer to link to this. But this is a lot more complex for both the consumer and the creator.
Have I got that right?
Thanks
Duncan
There's plus points for both methods. I for one, wouldn't use another person's Javascript on my page unless I was absolutely certain I could trust the source. It's not hard to make a malicious script that submits the values of all input boxes on a page. If you don't need access to the contents of the page, then using an iframe would be the best option.
Buttons and links can be "told" to navigate the top or parent frame using the target attribute, like so:
This is a link
<form action="http://some.url/with/a/page" target="_parent"><button type="submit">This is a button</button></form>
In this situation, since you're navigating away from the hosting page, the same-origin-policy wouldn't apply.
In similar situations, widgets are generally iframes placed on your page. iGoogle and Windows Live Gadgets (to my knowlege) are hosted in iframes, and for very good reason - security.
If you are using AJAX I assume you have a server written in C# or Java or some OO language.
It doesn't really matter what language only the syntax will vary.
Either way I would advise against the iFrame methods.
It will open up way way too many holes or problems like Http with Https (or vice-versa) in an iFrame will show a mixed content warning.
So what do you do?
Do a server-side call to the remote site
Parse the response appropriately on the server
Return via AJAX what you need
Display returned content to the user
You know how to do the AJAX just add a server-side call to the remote site.
Java:
URL url = new URL("http://www.WEBSITE.com");
URLConnection conn = url.openConnection();
or
C#:
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.WEBSITE.com");
WebResponse res = req.GetResponse();
I think you want to get away from using inline frames if possible. Although they are sometimes useful, they can cause issues with navigation and bookmarking. Generally, if you can do it some other way than an iframe, that is the better method.
Given that you make an AJAX reference, a Javascript pointer would probably be the best bet i.e. embed what you need to do in script tags. Note that this is how Google embed things such as Google Analytics and Google Ads. It also has the benefit of also being pullable from a url hosted by you, thus you can update the code and 'voila' it is active in all the web pages that use this. (Google usually use version numbers as well so they don't switch everyone when they make changes).
Re the credit card scenario, Javascript is bound by the 'same origin policy'. For a clarification, see http://en.wikipedia.org/wiki/Same_origin_policy
Added: Google Maps works in the same way and with some caveats such as a user/site key that explicitly identify who is using the code.
Look into using something like jQuery, create a "plugin" for your component, just one way, and just a thought but if you want to share the component with other folks to use this is one of the things that can be done.
How do I open 'cross-domain security', so the JavaScript on the page can freely communicate with the SWF, even when this is hosted on another domain?
I know for certain that this function communication is blocked by default, but by playing around with a file called "crossdomain.xml" and the actionscript 3 function: system.Security.allowDomain("*"). I'm not having full success though, and I don't have the insight to know which one is opening up for what.
Is there other hidden security layers, that I need to think of in this scenario?
And am I opening up my code for potential hackers somehow by doing this setup?
(and in case you're wondering: Yes, I have to make this work in a scenario, where the html is hosted on one domain, the JavaScript is added externally from another domain and the SWF is embedded by the JavaScript from a third domain - don't ask why, it's too complicated to explain - I too wish I could just host the whole thing in one domain).
Using Security.allowDomain("www.example.com") in the SWF will allow JS in a page from www.example.com to call functions exposed in the SWF with ExternalInterface.addCallback(). The domain and subdomain must match exactly. Using "*" will allow any domain to communicate with the SWF, but if you have one specific domain, it's better to use that.
Setting allowScriptAccess to always in the HTML embed code will allow the SWF to to call JavaScript functions.
One thing that catches many developers is that JavaScript will not be able to call functions on the SWF until the SWF is done loading. Unfortunately, there is no JS-based event that tells you when the SWF is ready (at least that I've found). What I usually do to work around this problem is call a JS function from the SWF immediately when the SWF finishes loading to notify the page that the SWF is ready.
There's some abstraction here and there, but if you take a look at the source code for YUI Charts, you might be able to figure out how Yahoo! got crossdomain JS/SWF communication working.
One thing I'd add to the previous answer: If you try the above code and it doesn't work, check to see if your site's address includes the "www" or not. Mine did not and didn't work if I wrote it as
Security.allowDomain("www.jeremy-knight.com");
I needed to write it as:
Security.allowDomain("jeremy-knight.com");