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

[Aaron Boodman]

Adding back webkit-dev...

On Thu, Apr 9, 2009 at 11:36 AM, Aaron Boodman <aa at chromium.org> wrote:
> Ok, so if I may sum up the conversation so far:
>
> * A static call out to a client is ugly, but OK as a temporary measure
> * You would like to see this mechanism replace the "local scheme"
> thing that already exists
>
> The local scheme feature is actually more powerful than just XHR, it
> also affects cross-site scripting. So I don't think that the refactor
> of permission logic into DocumentThreadableLoader would help us get
> rid of that.
>
> The current patch would, because it happens at the SecurityOrigin
> layer. The host return "yes, go for it!" for any schemes it considers
> "local". But that would make the static call out of SecurityOrigin
> permanent. We could make the client an instance member of
> SecurityOrigin, or some other object, but I don't really see how that
> makes it prettier; you'll still get calls on multiple threads.
>
> - a
>
> On Thu, Apr 9, 2009 at 1:14 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>>
>> On 09.04.2009, at 12:08, David Levin wrote:
>>
>>> Regardless of how it plays out in the future, I think that moving access
>>> control implementation to loader thread/process is a clear win.
>>>
>>> And if any help is still needed on this, I may be able to help with this
>>> in a few weeks, but I need to finish other things right now.
>>
>> It's rather unlikely that I will be able to work on this soon, so help from
>> you or other Chromium folks would be appreciated.
>>
>> This really looks like a significant architectural issue that we need to fix
>> sooner rather than later - it affects both workers, and the ability to
>> implement cross-origin redirects.
>>
>>> I'm also on vacation next week.
>>
>>
>> Cool, have a good time!
>>
>> - WBR, Alexey Proskuryakov
>>
>>
>>
>