7 ms·

Conceptual Overview XDomain will create an iframe on the master to the slave's proxy. Master will communicate to slave iframe using postMessage. Sl

Conceptual Overview XDomain will create an iframe on the master to the slave's proxy. Master will communicate to slave iframe using postMessage. Slave will create XHRs on behalf of master then return the results. XHR interception is done seamlessly via XHook. This sounds like some rather complex hack and to promote this as a silver-bullet instead of CORS seems a little odd or maybe even irresponsible to be honest. Q: But I love CORS A: You shouldn't. You should use XDomain because... Can you ensure that browsers or ad blockers won't block this kind of behaviour. Do you really want to go through those hoops just to save you from setting up a (server-side) proxy in the worst case, or try to get who you need to use CORS with to allow it on their domain?

esrauch 12y ago
> Can you ensure that browsers or ad blockers won't block this kind of behaviour > [...] or try to get who you need to use CORS with to allow it on their domain? There's no fundamental security difference between this and actual CORS since it requires the actual domain specifically serve a particular response to allow it. Either you have the ability to serve the proxy file from a particular domain and the general ability to set CORS headers, or you don't.
- e12e 12y ago
  I'm sorry, I've not looked at the code yet, but are you saying that being able to drop a html-file in some misconfigured servers public ftp-directory, or on some blogs upload folder is equivalent to being able to set http-headers? That's only true if CORS accept html-meta tags as replacement for http headers (which I don't think it does)? Again, I might be missing something, not having looked at the code yet, but it sounds like a rather strong statement.