Recently I was creating a test page (HTML) for injecting HTML from a TextArea into an iframe. Of course I was doing more than just that, but we don't need to go into it. I didn't want the Iframe to be on the same domain as the page (ie. I didn't want the injected HTML/JS to have access to the parent frame, the parent frame's DOM Storage, nor the parent frame's cookies). I of course -could- have just loaded in a random subdomain and injected it using innerHTML of the HTMLElement node, this would fix my problem, but it would be nice not to do that. So I chose to use Data URLs.
Big mistake.
Interestingly, the "domain" of a Data URL is an empty string. Which no matter what, is different than the parent frame - even running a local system file, the domain is "localhost", which is obviously not equal to the empty string and therefore cannot talk to each other. I tried to just set cookies or DOM Storage from this "" (empty string) domain, but Chrome throws Exceptions. I tried setting the document.domain of the parent frame to "", but again, got exceptions. Great, actually - all is working well, as it's supposed to, given Chrome's sandboxing. Just checking.
My real problem started when I mixed Flash into the equation.
The parent frame (either local or from web) can insert a Flash object which has access to the page scope. So from within the Flash, I can call functions which exist on the web page. This is critical to certain features of my SWF. There are restrictions to this too, but I'm fully aware of them and used to it - it all makes sense anyways, in regards to cross scripting and security.
However, the anomaly which sparked my interest was the fact that the Flash object in the "" domain simply cannot get access to the page scope, no matter how much the page and the swf want to talk. All I can figure is that Chrome sees the domain as "" and Flash sees the domain as something else, which would impose cross scripting security. But worse than that, it seems that Flash sees the "" domain as LOCAL (non-net) **, whereas Chrome sees it as just another domain.
** this was something I figured out later and made all the problems make sense. I just thought I was dealing with some bug or oversight, but it turns out I'm trying to hack my way through the most important Flash security.
This means that there is simply no way to enable page scope access for the SWF inside the Data URL page without going to the global Flash settings and allowing ALL domains here http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html .
Which most likely is something people aren't so willing to do. As a matter of fact, there's actually some bug there at the settings page when using both the "System" Flash settings AND the settings in the link there. Which means that devs like me who actually use the development features in that panel might have some problems.
This got me thinking about ways around this. As I said above at the **, I didn't realize yet I was dealing with intentional security. After all, I don't need complex communication - just some small strings. Passing TO the SWF is as always, super easy. But passing information FROM the SWF is not. Within the SWF, without ExternalInterface, one is limited to app settings and network connections. I tried changing app settings, things like name, id, width/height, dispatching events, etc etc, which I knew wouldn't work and sure enough, they didn't. Then I tried from the other directing, taking the DOM object, which is apparently called an "NPObject" (which is just a wrapper around Flash, meaning "native plugin object" I imagine, restricting access to the object). On pages where the SWF has access to the scope already, you can read and write attributes on it, but sure enough, didn't have any luck within the Data URL page. I tried tricks like a javascript url from the SWF, but that was blocked. I tried the hash message method, but again, didn't work - I think due to the Data URL. I did have one idea which seems rather exotic - since Flash is treating the app as local (if indeed it is), then I could change the page location to another Data URL which loads the SWF as a DataURL. This second SWF would appear to be from the same domain as the page and such get page access. Two big "IF"s with this - can you even use a Data URL for a Flash object, and even then, would it really allow page access? Maybe one day I'll try it.
UPDATE: I tried it. Didn't work. In modern versions of Flash they stopped the ability (as in, you used to be able to do it) to use Data URIs. It seems like a major security hole if it did work. I'm just a year or two too late. Drat.
No comments:
Post a Comment