[whatwg] Workers and URL origin check

[Dmitry Titov]

For me it feels the importScripts('foo.js') is a textual #include, while
Worker('foo.js') like a call into an enclosed component. :-)

It seems inheriting origin and base URLs from parent document may create
inconsistency for shared workers since it's unclear which origin and base
URL they should inherit from. Given that, perhaps it's better to keep the
current rule that origin and base are derived from the worker's URL, so
there is consistency between dedicated and shared workers.

Returning to the the narrower original question, what should we do with
redirects during worker loads?
- should we abort load if any URL in the redirect chain is from different
origin?
- should we only abort load if the final URL is from different origin?
- if the same site redirects between schemas (http->https, http->data etc)
does this abort loading too?
- which URL is used to compute the script's origin and/or base URL in case
of redirects?

The simplest solution is to just abort loading if origin deviates in any
part from parent context's, and use the final URL to compute origin (should
be the same) and base URLs.

I feel these should be covered in some parts of the spec.. I saw 6.4 of
HTML5 spec, but it does not cover the workers...

Dmitry

On Thu, May 28, 2009 at 9:50 AM, Drew Wilson <atwilson at google.com> wrote:

>
>
> On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>
>> On Wed, May 27, 2009 at 6:15 PM, Drew Wilson <atwilson at google.com> wrote:
>> > Along the same lines, I'm wondering why we require a same-domain check
>> for
>> > initial worker URLs, but not for script imported via importScripts().
>>
>> This is because workers run in a security context of the initial
>> worker URL. So this is the origin that is used for security checks
>> whenever the worker does something, like load data using
>> XMLHttpRequest.
>
>
> I'm not quite sure why importScripts() should behave more like a <script>
> tag than the Worker constructor itself. There's no reason why I shouldn't be
> able to do Worker("http://foo.com/worker.js") if I can do importScript("
> http://foo.com/worker.js").
>
>
>>
>> importScripts() however behave more like <script> in that they run the
>> loaded script in the security context of the worked that loaded them.
>>
>> > Seems
>> > like we ought to have workers inherit the origin of the script context
>> that
>> > invoked the Worker constructor, but allow the script URL passed to the
>> > constructor to point at any domain.
>>
>> That would be another solution to this problem, however some people
>> preferred the solution that is currently in the spec.
>
>
> Can anyone explain the motivation? A search of the archives isn't yielding
> anything particularly useful - the earliest mention I could find was someone
> from August of last year saying that essentially the same thing: "some
> people thought it was not safe" with no details.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090528/025cc670/attachment-0002.htm>