On 09.04.2009, at 1:23, Aaron Boodman wrote:
Rafael Weinstein, who is working with me, consulted with Adam Barth
and submitted a patch based on his ideas
<https://bugs.webkit.org/show_bug.cgi?id=24853> for this a few weeks
back. It has met with resistance though, and we're not really sure
where to go next.
I discussed this with Rafael over IRC a few days ago, and it seems
that the biggest issue is entirely Chrome-specific. As all extensions
share the same URL scheme, it is not safe to give them different
privileges. As a comment in SecurityOrigin says,
// <...> Granting privileges to some, but not all, documents
// in a SecurityOrigin is a security hazard because the documents
without
// the privilege can obtain the privilege by injecting script into
the
// documents that have been granted the privilege.
Is there a solution for this issue already, or is it something the
Chrome team is willing to ignore as a low risk threat?
With an answer to this question, we can discuss the technical
approaches, but here are some preliminary comments.
* Some people don't like the idea that the callback gets invoked on
multiple threads.
I don't like this idea, but as I said on IRC, it is acceptable to have
this as a temporary solution. However, I wonder how this will work in
Chromium for XMLHttpRequest calls made from workers, with the loader
being in a different process, not a different thread.
* some people think it's ugly to have SecurityOrigin making calls out
to static methods and think it should have a normal instance client.
I mostly agree with that - I think that this should be done via
FrameLoaderClient. I also think that the solution should obsolete and
remove FrameLoader::registerURLSchemeAsLocal().
I was hoping
that I could add a method to FrameLoaderClient and call it from XHR,
but I don't see a nice way to get to FrameLoaderClient from XHR.
Same question - with FrameLoaderCleint being in a different process
for XHR in workers, I don't see how this could possibly work. Am I
perhaps misunderstanding the Chromium loader architecture?
4) Refactor all access checking (current same-origin checks, "local
scheme" stuff, preflight stuff for AC) into DocumentThreadableLoader.
Then add a new callback for what we want on FrameLoaderClient. One
meta-question I have about this approach is whether it's really the
right thing to do XHR-specific access checks in
DocumentThreadableLoader and friends. In general, I'd rather not
embark on a big refactor to get this done, but I'm still open to it if
that's the only option.
At least the preflight stuff for AC logically belongs to
DocumentThreadableLoader - we need to move it there to reasonably
implement redirects for cross-origin requests. The rest (which I think
is just canLoadLocalResources checks for Dashboard) isn't relevant to
this discussion, because these checks do not access static data.
- WBR, Alexey Proskuryakov
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
