[webkit-dev] Regarding SecurityOrigin API usage

[Pushparajan V]

On Fri, Jan 7, 2011 at 1:18 AM, Adam Barth <abarth at webkit.org> wrote:
> On Thu, Jan 6, 2011 at 6:27 AM, Pushparajan V <vprajan at gmail.com> wrote:
>> I have a query regarding addOriginAccessWhitelistEntry API in
>> SecurityOrigin.cpp. Is there any special requirement in the
>> sourceOrigin argument of this API when the scheme of the sourceOrigin
>> is already added to the localScheme list?
>
> There's a long-standing issue here that some of the checks for
> whitelisting and being local are backwards.  I tried to fix this
> recently, but that caused a performance regression because the
> canDisplay method is apparently very hot in the page load test.  I
> need to circle back and give it another shot.
>
>> Because if the sourceOrigin is localScheme and the URI doesn't have a
>> path, this API fails miserably without any warning or asserts.
>
> Sorry.  :(
>
>> For example, if widget is a local scheme and the source origin URI is
>> widget://884889/ for which i need to whitelist some destination URLs,
>> the below statement returns null.
>>
>>    String sourceString = sourceOrigin.toString();
>
> That behavior is actually correct.  By default, we treat local origins
> as if the were sandboxed with the unique origin bit.  What's your
> motivation for marking widget as a local origin?

Since widget accesses files in local filesystem, this marking is done.
As you said, this new unique origin bit used for sandboxing is the
reason behind null getting returned by toString.

>
> The same change I mentioned above is mostly concerned with
> crystalizing out the two properties we have tied up in "localness,"
> which are blocking navigation to local URLs and special access status
> for them (historically universal access, more recently sandboxed
> access).

There is a fear of losing compatibility with the latest HTML5
localSchemes like data://, sandbox:// etc. That's the reason widget
scheme wanted to be kept as local.


>
>> After debugging more, found that all local schemes are treated as
>> file:// schemes and directory access is not allowed for any
>> localScheme.
>
> Yeah, I think that's what I meant above by "sandboxed" but I could be
> misunderstanding.
>
>> Does that mean securityOrigin's should be created always with full URLs?
>
> You can't round-trip SecurityOrigin objects via toString.  There are
> several things that aren't represented in the string version,
> including document.domain and the HTML5 sandbox bits.
>
> I'm not 100% sure I answered your question, but I suspect the solution
> might be to avoid marking widget as a local scheme.

Yeah that would be the perfect fix. Moreover, this is what tried out
recently and working well.

But the only problem suspected with this is blocking of
navigation/access with other internal localSchemes (like file, data).
Need to test and study that flow as well to come with a conclusion.

Thanks Adam. It answered many of my questions in one shot. :)


>
> Adam
>



-- 
Pushparajan V
http://vprajan.blogspot.com