W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2012

(unknown charset) [whatwg] File based permission files?

From: (unknown charset) Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Wed, 25 Apr 2012 22:33:12 +0200
Message-ID: <4F985F88.1030806@bauglir.com>


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
Received on Wednesday, 25 April 2012 13:33:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT