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

[Alexey Proskuryakov]

On 09.04.2009, at 11:38, Aaron Boodman wrote:

> Chromium extensions run in the same scheme (chrome-extension://), but
> they do not run in the same origin. They all have unique origins of
> the form chrome-extension://<extension-id>/. Security origin is scheme
> + host + port.

OK, I didn't know that the scheme was hierarchical (seems obvious in  
hindsight). So, we don't have any major problems with this feature!

> I don't mind doing it on FrameLoaderClient. Forgive the noob question,
> but I'm newish to webkit... How should this be plumbed?

I don't have a definitive answer (which is why I originally suggested  
modeling the solution after FrameLoader::registerURLSchemeAsLocal()  
and avoiding callbacks). Clearly, doing it on FrameLoaderClient is no  
different from doing it via a non-static call on any other client  
class, like the potential ScriptOriginClient - either ScriptOrigin  
will need to keep a pointer to client class, or all callers will need  
to pass it with each call.

>> 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.
>
> But how will DocumentThreadableLoader know what policy to apply?  Some
> things are allowed to be loaded across origins (iframes) without AC,
> and some things aren't (XHR). Maybe I am misunderstanding and
> DocumentThreadableLoader is only used for XHR? Or maybe there is some
> context that will be available?
>
> I'm sure I'm just misunderstanding here, I'm just curious what you had
> in mind more than anything.


ThreadableLoader is used for different things indeed, but it is is  
already configurable (e.g. whether to do content sniffing, or to use  
loading callbacks), and could take more configuration options.

I see it as a bottleneck for DOM-initiated loading - that is,  
everything that can be initiated from a worker, as opposed to markup.  
The distinction is admittedly rather vague - e.g. if we ever allow XML  
DOM and XSLT in workers, XSL stylesheets will need to be loaded  
through this interface, too (but those are also known to be a  
potential future application of cross-origin access control).

Regardless of how it plays out in the future, I think that moving  
access control implementation to loader thread/process is a clear win.

- WBR, Alexey Proskuryakov