[webkit-dev] SharedWorker design doc

[Maciej Stachowiak]

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/ab25aad7/attachment.html>