System.download [was ...]
On Mon, Jul 9, 2012 at 7:04 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
I would like to have the final word on that one.
If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some "manipulations", then it's better to have something clean.
The same-origin policy is not the responsibility of TC39, and more importantly it's not something that I can speak with the requisite authority about. Adding a convenience for fetching data using the current fetch hooks of loaders is a possibility, but I don't want to add more conveniences before it's clear they're useful.
I have given some examples, surprising that nobody else reacts with other examples. One of the use could be to be able to do the very simple thing :
var f=function() {
var a={};
var cb=function(code) {System.eval(code);console.log(a.b)};
System.download(url,cb);
//url's code --> a.b='b';
}
Where System.eval does a simple eval if url is not a module.
Or something like that, why do we have the eval(src) possibility in the proposal if we can not fetch src ?
Le 10/07/2012 01:48, Aymeric Vitte a écrit :
On Tue, Jul 10, 2012 at 7:36 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
I have given some examples, surprising that nobody else reacts with other examples. One of the use could be to be able to do the very simple thing :
var f=function() {
var a={}; var cb=function(code) {System.eval(code);console.log(a.b)}; System.download(url,cb); //url's code --> a.b='b';}
Where System.eval does a simple eval if url is not a module.
Right, that's what loader.eval is specified to do for module loaders.
Or something like that, why do we have the eval(src) possibility in the proposal if we can not fetch src ?
Because browser embeddings of JS already provide XHR. If you don't like the XHR API (I certainly am not a fan), then there are places to talk about that.
On Mon, Jul 9, 2012 at 6:04 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some "manipulations", then it's better to have something clean.
Please do explain what "manipulations" you have in mind here.
As I understand it, the same-origin policy is what prevents other web sites you visit from sending HTTP requests to your bank (for example), with your login cookie attached, and looking at the responses. It seems like it would be a major security hole if that could be easily circumvented.
Le 12/07/2012 01:17, Jason Orendorff a écrit :
On Mon, Jul 9, 2012 at 6:04 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some "manipulations", then it's better to have something clean. Please do explain what "manipulations" you have in mind here.
As I understand it, the same-origin policy is what prevents other web sites you visit from sending HTTP requests to your bank (for example), with your login cookie attached, and looking at the responses. It seems like it would be a major security hole if that could be easily circumvented.
-j
Your example is specific, you need first to get the bank cookie which is not easy. More generally, MDN docs state :
"The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin."
Then same MDN docs say :
"|window.postMessage| is a method for safely enabling cross-origin communication. Normally, scripts on different pages are only allowed to access each other if and only if the pages which executed them are at locations with the same protocol (usually both |http|), port number (|80| being the default for |http|), and host (modulo document.domain developer.mozilla.org/en/DOM/document.domain being set by both
pages to the same value). |window.postMessage| provides a controlled mechanism to circumvent this restriction in a way which is secure when properly used."
Then for example postMessage is breaking the first statement, not saying that it is not usefull, we did use it here extractwidget.com/#demo, you go on a site, inject the code, select your gadget and then via iframe and postMessage you login and record the gadget on our site, but "which is secure when properly used" indicates that some bad uses could be made.
There is the cross domain xhr with access control too.
But coming back to my point, I am not talking about a download like a xhr where you can set cookies, do post requests, etc, just a download that fetch the source, so I don't see it more dangerous than script or img fetching (or System.load) for example.
Le 10/07/2012 13:40, Sam Tobin-Hochstadt a écrit :
On Tue, Jul 10, 2012 at 7:36 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
Where System.eval does a simple eval if url is not a module. Right, that's what
loader.evalis specified to do for module loaders.
Where is it in the proposal ? I can not find it, what kind of eval does it do in that case ? What I see is :
"Reflective evaluation, via |eval| or the module loading API harmony:module_loaders starts a
new compilation and linking phase for the dynamically evaluated code. As in ES5, the direct |eval| operator inherits its caller’s scope chain."
But again, difficult to eval something that you can not fetch...
On Fri, Jul 13, 2012 at 3:39 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
But coming back to my point, I am not talking about a download like a xhr where you can set cookies, do post requests, etc, just a download that fetch the source, so I don't see it more dangerous than script or img fetching (or System.load) for example.
It's the difference between exposing every image on your intranet to any random web page that asks for it, and exposing all data on your intranet to any random web page that asks for it. Any web page could start by fetching "intranet" and follow the links from there. This kind of comprehensive spidering of an organization's internal data is obviously not possible with <img>.
This is basic browser security stuff. I strongly suggest reading up before posting anything more on this topic.
Yes it's true, focusing too much on my needs, then forget it Le 13/07/2012 11:39, Jason Orendorff a écrit :
I would like to have the final word on that one.
If the answer is that it is not possible because of the same origine policy, then it is not difficult to show that this policy can be broken already, by some "manipulations", then it's better to have something clean.
Le 06/07/2012 19:21, Aymeric Vitte a écrit :