Last Comment Bug 756589 - testcase: importScripts works only with same-origin
: testcase: importScripts works only with same-origin
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: SocialAPI (show other bugs)
: unspecified
: x86 Mac OS X
: -- blocker (vote)
: ---
Assigned To: Shane Caraveo (:mixedpuppy)
:
: Shane Caraveo (:mixedpuppy)
Mentors:
Depends on:
Blocks: 733414
  Show dependency treegraph
 
Reported: 2012-05-18 13:27 PDT by Shane Caraveo (:mixedpuppy)
Modified: 2012-05-28 12:06 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Shane Caraveo (:mixedpuppy) 2012-05-18 13:27:47 PDT
The code does use nsIURI.resolve on any urls passed to importScripts, we should have a unit test for that.  As well, importScripts should support data URIs.
Comment 1 Mark Hammond [:markh] 2012-05-20 17:59:28 PDT
Please clarify: does this mean the "same origin" used by the browser itself, or the more relaxed "provider origin" we are using (which doesn't include the scheme)?  The distinction may be important.

Also, what is the use-case for supporting data URIs?  IIUC, a data url would have the javascript source embedded in it, so eval() could be used directly by the worker to support this?
Comment 2 Shane Caraveo (:mixedpuppy) 2012-05-20 23:19:41 PDT
importScripts is defined in the web worker spec.  IIUC, you can only import relative scripts, or at most same origin (proto+host+port) urls.

http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html
section 9.3.1
Comment 3 Mark Hammond [:markh] 2012-05-21 19:50:47 PDT
I'm actually not sure the worker spec says this at all:

* 
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html implies the origin is used to resolve relative URLs.  9.3.1.4 has the word "fetch" with a link, and following that link it mentions an optional "same-origin flag" - but 9.3.1.4 doesn't mention this flag - just the "synchronous flag".

* http://petelepage.com/blog/2011/05/tweeterfall-web-workers/ has an example where importScripts is used to load from twitter.com.

* http://code.google.com/p/chromium/issues/detail?id=70336 is a chromium bug which talks about information leakage in cross-origin importScripts.  It implies the error is simply the leakage, not the fact that cross-domain importScripts works.

* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017543.html implies no such restriction too.

FWIW though, gecko *does* currently have such restrictions - http://mxr.mozilla.org/mozilla-central/source/dom/workers/ScriptLoader.cpp#296 - but that may well end up being considered a bug...

All that said though, it would be prudent for us to enforce it too.  I think this means we should *only* accept relative URLs, otherwise we end up with a problem of http:// vs https:// (ie, bug 756021 is so we can have the same provider from a http and https URL, but if we enforce the same origin restriction here, the worker can't use a fully-qualified URL as either the http or the https one will fail to load in the other context)
Comment 4 Shane Caraveo (:mixedpuppy) 2012-05-28 12:06:17 PDT
for now, enforcing same-origin for importscripts.  We can loosen later if that makes sense.

pushed https://github.com/mozilla/socialapi-dev/commit/ba53096bdf93f614d38776e5e9cf78404852c924

Note You need to log in before you can comment on or make changes to this bug.