[webkit-dev] SharedWorker design doc

[Drew Wilson]

That's also a reasonable option - so we'd just return a 401 error to the
caller if the initiating window is unable to gather credentials.
-atw

2009/4/22 Maciej Stachowiak <mjs at apple.com>

>
> On Apr 22, 2009, at 11:54 AM, Drew Wilson wrote:
>
> Following up on this - is using a dialog for HTTP auth for worker requests
> really such a bad thing? What if we only do this as a fallback, in the case
> that the initiating window is closed?
> It seems more like a UX issue that the application itself could manage (if
> you want to use HTTP Auth from your workers, then be sure to force the auth
> to happen before your window closes).
>
>
> It's not only a problem for the Web application but also a problem for the
> browser:
>
> 1) We don't want the UI to be confusing even if a Web application is
> written without sufficient caution.
>
> 2) We don't want to create a phishing risk via SharedWorkers throwing up
> auth dialogs that appear to belong to another window.
>
> One possible solution is that if the frame that created the SharedWorker
> originally is now gone, then any network request that would lead to an
> authentication prompt or other kind of prompt fails. That allows the
> solution you propose for Web apps, but prevents confusion and abuse in the
> case of malicious or poorly written Web apps.
>
> Regards,
> Maciej
>
>
>
> -atw
>
> 2009/4/22 Drew Wilson <atwilson at google.com>
>
>> That's an excellent point about HTTP auth.
>> I'm not sure that the "let's just go find an open frame associated with
>> this worker" solution will work - the reason is that with the ability to
>> create/pass around message ports, you can end up with the worker associated
>> with a frame from a different domain (window A creates worker B, then passes
>> worker B's MessagePort to window C which is running under a different domain
>> - once window A closes, worker B can't load through window C because it's a
>> different domain).
>>
>> Clearly being able to pass MessagePorts around is a bad idea :)
>>
>> -atw
>>
>> 2009/4/21 Alexey Proskuryakov <ap at webkit.org>
>>
>>
>>> 22.04.2009, в 2:31, Drew Wilson написал(а):
>>>
>>>  David's take is that long term we'll need to change the loader code so
>>>> it is not dependent on a specific frame - his upcoming refactoring may
>>>> facilitate this, but there will still be a significant amount of work to
>>>> achieve this in WebKit. Over the short term, he suggested that we might be
>>>> able to suspend the parent frame, such that it still exists for the purposes
>>>> of allowing associated workers to perform network loads, but it itself no
>>>> longer has an open window and its active DOM objects are shutdown. When the
>>>> last child worker exits, the parent frame can be completely discarded.
>>>>
>>>
>>> A problem with this approach is communicating to the user - e.g. asking
>>> for HTTP authentication credentials. Without an open window, it won't be
>>> possible to display a sheet, and if we were to display a dialog window
>>> instead, the user wouldn't know which site needs the credentials.
>>>
>>> We do need to make loading work for frameless documents (e.g. to support
>>> XSLT document() function), but in other cases I'm aware of, we can rely on a
>>> parent window being visible.
>>>
>>> - WBR, Alexey Proskuryakov
>>>
>>>
>>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090422/65725df9/attachment.html>