New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify origin restrictions #5

Closed
slightlyoff opened this Issue Feb 7, 2013 · 13 comments

Comments

Projects
None yet
5 participants
@slightlyoff
Copy link
Contributor

slightlyoff commented Feb 7, 2013

Right now the CachedResponse is the only x-domain type of Response that handles x-domain sanely. I.e., to serve an x-domain image, you must first add it to a Cache and then respondWith(cachedItem). This is inelegant.

@wycats

This comment has been minimized.

Copy link

wycats commented Feb 7, 2013

It would be better if it was possible to make an explicit request for cross-browser content that returned a Blob that could be used with other APIs, but with contents inaccessible to JavaScript. Then, this (straw man alert) OpaqueBlob could be made the source of an img, script, etc. without changing the security model at all.

@slightlyoff

This comment has been minimized.

Copy link
Contributor

slightlyoff commented Feb 7, 2013

So, if XHR responses can work with respondWith(), CORS already opens up many x-domain options.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 11, 2013

We should have a new XHR-like API that takes a Request and returns a Future<Response>. The caveat is that depending on the Request settings, you might not be able to read the Response, but can still use it. response.body could still be available I suppose and always return an opaque Blob.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 11, 2013

Duplicate of #7?

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 26, 2013

If we allow workers from another domain, we need to clarify what the requesting origin of the worker would be. Feels like it should be the origin of the scope, not the worker itself. Otherwise there'll be confusion over what the worker thinks is cross-origin and what the page thinks.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Sep 26, 2013

Are we planning on allowing that? I thought that was disabled. It's allowed for shared workers, but there's less risk there. In any event, we should use the same setup as shared workers have I think. Introducing a new model would be confusing.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 26, 2013

Didn't realise we allowed it in SharedWorkers, was reading an old version of the spec. What's the model in SharedWorkers? Is the origin the origin of the worker script or the origin of the page that owns the worker?

We discussed ServiceWorkers on other domains over at #46 - disabled by default but allowable via CSP seemed to be the consensus. I'm not particularly attached to the idea, wouldn't be against dropping it.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Sep 26, 2013

The origin comes from the entry script's origin that instantiates the worker. See http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-sharedworker step 8 substep 8.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 26, 2013

Ok, that pattern makes sense for ServiceWorkers if we allow other domains, although it'll be the "registering script" rather than "entry script", since the ServiceWorker can start up without an attached window.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Sep 26, 2013

Sure, but it'd still be the entry script's origin ;-) It would just be stored. I guess the other implication of that is that they should only work for http/https. E.g. data URLs can generate a unique origin for which they would not make much sense.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 26, 2013

Excellent. Yeah, we don't want to support datauris for controllers, aside from this issue they also can't update so create lock-in.

@KenjiBaheux

This comment has been minimized.

Copy link
Collaborator

KenjiBaheux commented Aug 5, 2014

Given the date of the last update, did this issue outlive its purpose? I assume that this isn't the case but is there anything that needs to be reflected in the spec or discussed further?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 5, 2014

This is out of date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment