On 25.4.2012 22:01, 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.
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.
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.
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.
-Tyler Larson
your solution have several issues:
1/ yet another request
a) you make prefligh request
b) you make xml file request
c) you download data
2/ those specification are not 1:1 compatible, how should those be
combined? Should they be combined?
3/ there may be collision in HTTP headers and you XML file, one negating
setting of the other. Which should take precedence?
a) HTTP over XML file? then you solution makes no sense (since default
server settings disallows CORS, XML has no chance here)
b) XML over HTTP? I doubt W3C and browser vendors would be happy with
specification they have no control over, and one thing is how Adobe is
managing policy in their Flash, another thing is to get consensus among
all parties within whole W3C (Adobe can change their specification and
implement it in Flash as Adobe see fit, without any consensus, this is
not possible for W3C / browser vendors)
4/ changes in one could create pressure to change the other and the
other party may not be willing to do so... and we are back in combining
/ precedence issue
You simply have to make a pressure on sharing services, that if want to
share data, they have to allow it. And if they do not want to allow it,
they simply do not want to share... and that is why we have CORS... Yes,
they will either solve it by reconfiguring server, or some domain level
policy file specific to server could solve it (e.g. .htaccess)
Brona
