[webkit-dev] Allowing webkit clients to extend XHR security policy

[Aaron Boodman]

It sounds to me like our current patch is the best fit because it fits
our needs, will work with Chromium's out-of-process workers, plus it
allows us to remove FrameLoader::registerURLSchemeAsLocal() as Alexey
requested. It has the downside that the client will get called on
multiple threads, but this will automatically be fixed when the
DocumentThreadableLoader refactor work is done.

Can I get a yay or nay (from Alexey or other interested people) on
moving forward with that patch? We're happy to do the work to remove
registerURLSchemeAsLocal() while we're in there.

Alternatively, can I get an idea for a different approach that would
be accepted?

Thanks,

- a

On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman <aa at chromium.org> wrote:
> On Thu, Apr 9, 2009 at 9:50 PM, David Levin <levin at google.com> wrote:
>>
>> On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
>>>
>>> On 09.04.2009, at 22:38, Aaron Boodman wrote:
>>>
>>>> The local scheme feature is actually more powerful than just XHR
>>>
>>> If you only need extensions to do XHR, why not just make them use
>>> cross-origin XHR? That way, the extension won't even need to declare the
>>> origins it's going to access - all checks will be server-side, as with
>>> normal cross-origin XHR.
>>
>> I think the idea is that a user could install an extension and the user
>> could trust the extension to do the cross-origin xhr (without the server for
>> the x-origin doing anything special).
>> For example, I used to have the book burro FF extension
>> (http://www.bookburro.org/) which displayed prices for books from several
>> book stores when you visit another online book store.
>
> Exactly. Sorry for not making this clear in the original mail.
>
> - a
>