Hello all, I'm working on adding extensions (aka "Add-Ons") to Chromium. One thing we want to enable these extensions to do is to make limited cross-origin XMLHttpRequests.
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. So I wanted to back up, explain what we're trying to do at a high level and get suggestions for the best way to implement this. The Goal: We want extension developers to be able to access multiple origins, but for them to have to declare those origins ahead of time. The origins would be declared using a pattern syntax, something like 'http://*.google.com'. Having to declare the origins ahead of time reduces the damage a compromised extension can do because it can only be used to access a subset of origins. Most use cases we envision really only need to access a few origins, so this would be a big win for us. This also seems like this is something that could be generally useful for other webkit clients. I can imagine browsers wanting to offer increased privilege modes to web apps, and then wanting to do similar restrictions on access to cross-origin XHR. Ideas: 1) A static call out of WebKit to a client from SecurityOrigin. This is the current patch. A few problems people have brought up with it: * Some people don't like the idea that the callback gets invoked on multiple threads. * some people think it's ugly to have SecurityOrigin making calls out to static methods and think it should have a normal instance client. 2) Non-static SecurityOriginClient. I suggested this in the last comment on the bug. The creator of a SecurityOrigin would have the option to set a client which it could retrieve from FrameLoaderClient (or some other client?). This doesn't solve the problem of getting callbacks on multiple threads, but we could skip implementing it for workers and when the refactor to move origin checking for workers to the UI thread happens, it will automatically start working. 3) Something more specific to XMLHttpRequest. Since we're really only interested in modifying the behavior of XMLHttpRequest, it might be nicer to do something more targetted than SecurityOrigin. 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. 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. That's about all the ideas I've come up with. Are any of them appealing? Is there some other approach that would be better? I think we can also do this outside of WebCore with some hacking, but I'd rather avoid that and contribute some useful code to WebKit at the same time if possible. - a _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev