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 <atwil...@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 <a...@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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
