[webkit-dev] Regarding SecurityOrigin API usage

[Adam Barth]

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?

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).

> 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.

Adam