- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 25 Apr 2012 13:19:09 -0700
On 4/25/2012 1:01 PM, Tyler Larson wrote: >> You can do cross-domain permission via IFRAME and postMessage. >> Now that transfer semantics are widely accepted, you can efficiently send an array buffer across frames. >> >> So you setup something like trampoline.html, you connect to it via iframe and send it a message, then trampoline.html does an XHR request (in its own domain) and sends back the data. >> It's better than a .xml file because it's scriptable. >> >> -Charles >> > Good to know, I haven't used this before but it still seems to be intended for a different use case. > I'm basing my knowledge on write ups like this, https://developer.mozilla.org/en/DOM/window.postMessage > From my understanding the pixel data would need to be loaded into the iframes page, that page would then get the pixel data and post that data back so that I could then use it. Yes, you'd send pixel data or you'd send the file data (as received from XHR as an array buffer or blob). > I can get around my issue a bunch of different ways and people will be forced to create all forms of hacks and proxy servers to make their applications work but based on the things I have seen, what you are suggesting is far more complicated than a standard crossdomain.xml setup. Setting something up once and moving on, rather than needing to script a communication layer between what files you want to load and sending that information across a messing system. It's not very complicated, it's a few lines of code. It's certainly more complicated than things "just working" with crossdomain.xml and/or CORS. But it is a solution that works across all browsers that work with postMessage. It's also a solution that we may see more of with things like web intents and wider use of SharedWorker. > I still think that my proposal is valid. > Lets say I am building anything using the canvas that loads images from anywhere else on the internet and then wants to manipulate them. > If javascript used the same setup, a crossdomain.xml file would be loaded without the developer needing to do anything as soon as they requested something that needed the permissions. An event would be fired if this you tried to do something that you didn't have permissions to do, otherwise everything would just work. Your proposal is certainly valid. Currently one could probably use Flash for crossdomain.xml. You're looking to put something out there that people can use without needing to change settings on their web host. That's a reasonable goal. And crossdomain.xml did work well for a limited set of cases with Flash. I'm just saying that we have methods in place today that do work. > The current COR setup is also transparent which I like, what I don't like about it is simply that system admins will fight needing to reconfigure their servers to add these headers leaving developers unable to use these features. If we make use of the security files already in place we can get going on canvas based image manipulation today without anyone needing to change anything. Seems like it's about four lines of code in Flash: http://stackoverflow.com/questions/1088323/flash-crossdomain-xml-problems postMessage isn't much different. I doubt you'll see vendor buy-in on the proposal simply because so much is working with web messaging. -Charles
Received on Wednesday, 25 April 2012 13:19:09 UTC