[webkit-dev] Allowing webkit clients to extend XHR security policy
ap at webkit.org
Thu Apr 9 01:01:57 PDT 2009
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
>> 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
More information about the webkit-dev