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 <m...@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 <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
